TECHNICAL FIELD [001] It is desirable to know the up-to-date state of the traffic before setting on a trip or while on the journey. While in some countries, there are sensors and areal reporters that inform drivers of the state of the major highways and streets, it is more difficult to monitor the traffic state in dense urban or suburban roads. To have continuous information on the state of traffic in city "hot-spots", dedicated sensors have to be deployed at the locations. However, in the case of an accident, broken traffic light or road works that happen where there are no traffic sensors, it is unlikely that the drivers heading to the effected parts can be informed in time to avoid these areas. At the same time, placing traffic sensors on every part of the highway and major and minor roads is an expensive exercise and not practical in most cities and roads. Therefore, it is desirable to have a real-time traffic monitoring system of the entire road system, without the need for dedicated sensors and communication network.

BACKGROUND ART [002] The novel invention disclosed here provides a cost effective method for providing real-time traffic information at any location, without the need of dedicated sensors. The capability of being able to download and execute application softwares within Smartphones, such as Google "G1" or Apple "iPhone", makes these devices ideal as mobile sensors, to gather information from the locations they roam around in. Most of these so called Smartphones are equipped with positioning devices such as GPS and/or AGPS and accelerometer which makes them ideal as "mobile traffic sensors". As these devices become more prevalent, even if a portion of the subscribers using Smartphone (e.g. taxi drivers and public or commercial transport drivers), are encouraged to allow their Smartphones to become traffic sensors, it is possible to have up-to-date traffic reports from places where these vehicles travel to and from. To encourage Smartphone subscribers to allow their phones to be used as traffic sensors, they may be given free minutes by their operators or be allowed to receive traffic updates as a member of a closed user group that provide traffic report updates.

[003] For the purposes of describing the novel idea here, WCDMA cellular network is used as the example cellular network. However, it is understood that with the appropriate modifications, the same invention can be used in other networks such as cdma2000, GSM, LTE and WiMax. It is also possible to use shorter range wireless networks such as WiFi or BlueTooth, with a Smartphone or device that can support them.

[004] For the purposes of describing the novel idea here, Google G1 is used as the example Smartphone. However, it is understood that with the appropriate modifications, the invention can be used with any Smartphone that preferably has the "background processing" and positioning (GPS or AGPS) capabilities, or any other device that has positioning capability with the ability to communicate with a wireless network.

[005] For the purposes of describing the novel idea here, Short Message Service (SMS) is used as the example bearer service. However, it is understood that, with the appropriate modifications, any circuit or packet switched bearer services such as voice or data, or MMS or EMS can be used instead or as well as SMS.

SUMMARY

[006] A traffic monitoring system and apparatus based on cellular system, comprising of at least a cellular network unit and at least a cellular mobile unit, where the cellular mobile unit has the capability of collecting data at its approximate location for further processing to estimate mobility information, where the mobility information includes; Mobile mobility type, Mobile maximum, average speeds and steady state speed, Mobile average and maximum accelerations, Mobile position, Mobile direction of travel, Mobile recent turns and Time of collected data. The mobile unit then presents the collected data or the processed mobility information to the cellular network unit, periodically or when interrogated by the cellular network unit, where the mobility information is collected and further processed in isolation or in conjunction with other mobility information from the same or other mobiles, to estimate the traffic status for the geographical area associated with the mentioned mobility information.

BRIEF DESCRIPTION OF DRAWINGS

[007] Figure 1 represents an example block diagram of WCDMA (or UMTS) network.

[008] Figure 2 represents an example of Computing Device (e.g. G1 Smartphone).

[009] Figure 3 represents an example block diagram of "Network Based" traffic reporting system.

[0010] Figure 4 represents an example of highway segment histogram.

[0011] Figure 5 represents an example of dense-urban street segment histogram. [0012] Figure 6 represents an example of UE speed profile on a highway.

[0013] Figure 7 represents an example of UE speed profile on a dense-urban street.

[0014] Figure 8: represents an example of GPS sample measurements with a vehicle moving on a straight line.

[0015] Figure 9 represents an example of GPS sample measurements with a vehicle moving on a curved line.

[0016] Figure 10 represents an example of field allocation for "Traffic Report Request".

[0017] Figure 11 represents an example of field allocation for "Traffic Report Response".

[0018] Figure 12 represents an example block diagram of "Stand-alone" traffic reporting system.

[0019] Figure 13 represents an example flowchart of "TRAS Control Program".

[0020] Figure 14 represents an example flowchart of "TRAS Analysis Program".

[0021] Figure 15 represents an example flowchart of "UE Traffic Report program".

[0022] Figure 16 represents an example flowchart of "UE speed Estimation Program".

[0023] Figure 17 represents an example flowchart of "UE Mobility Identification Program".

DESCRIPTION OF EMBODIMENTS

[0024] Figure 1 shows an example block diagram of a WCDMA (or UMTS) network, with some blocks such as "Billing server", EIR and OMC not shown. In this example, the User Equipment (UE) is shown as a Google G1 Smartphone and hereafter is referred to as "UE" or "computing device". All network elements and interfaces are known to a person sufficiently skilled in the art.

[0025] Computing device shown in Figure 2 is intended to represent various forms of mobile devices, such as personal digital assistants, cellular telephones, smart phones, and other similar computing devices. The components shown here, their relationships and their functions, are meant to be exemplary only, and are not meant to limit implementations of the inventions described and/or claimed in this document. The computing device shown in Figure 2 can also be used as representative of Google G1 Smartphone. Figure 2 does not show all the components of a Google Smartphone G1 , but does show the units in a Smartphone G1 that are relevant to the novel idea disclosed here. Figure 2 does not show the internal connections of the units or interfaces or input/output ports or antennas of the G1 smartphone.

[0026] Computing device shown in Figure 2 includes a processor unit, memory unit, a display unit, a communication interface labeled "control unit", a WCDMA, a GPS, a Bluetooth and a WiFi unit, among other components. The Computing device shown in Figure 2 may also be provided with a storage device, such as a microdrive or other device, to provide additional storage. All of the shown units in Figure 2 are interconnected using various buses, and several of the components may be mounted on a common motherboard or in other manners as appropriate. The processor unit can execute instructions within the computing device, including instructions stored in the memory unit. The processor unit may be implemented as a chipset of chips that include separate and multiple analog and digital processors. The processor unit may provide, for example, for coordination of the other components of the computing device, such as control of user interfaces, applications run by computing device, and wireless communication by the computing device. Processor unit may communicate with a user through control unit and display unit. The display unit may be, for example, a TFT LCD (Thin-Film-Transistor Liquid Crystal Display) display or an OLED (Organic Light Emitting Diode) display, or other appropriate display technology. The display unit may comprise appropriate circuitry for driving the display to present graphical and other information to a user. The control unit may receive commands from a user and convert them for submission to the processor unit. In addition, an external interface (not shown) may be provide in communication with processor unit, so as to enable near area communication of the computing device with other devices. The external interface may provide, for example, for wired communication in some implementations, or for wireless communication in other implementations, and multiple interfaces may also be used. The memory unit stores information within the computing device. The memory unit can be implemented as one or more of a computer- readable medium or media, a volatile memory unit or units, or a nonvolatile memory unit or units. Expansion memory (not shown) may also be provided and connected to the computing device through an expansion interface (not shown), which may include, for example, a SIMM (Single In Line Memory Module) card interface. Such expansion memory unit may provide extra storage space for the computing device, or may also store applications or other information for the computing device. Specifically, expansion memory unit may include instructions to carry out or supplement the processes described above, and may include secure information also. Thus, for example, expansion memory unit may be provided as a security module for the computing device, and may be programmed with instructions that permit secure use of the computing device. In addition, secure applications may be provided via the SIMM cards or over-the-air via one of the wireless interfaces such WCDMA unit, (along with additional information such as placing identifying information on the SIMM card) in a non-hackable manner. The memory unit may include, for example, flash memory and/or NVRAM memory, as discussed below. In one implementation, a computer program product is tangibly embodied in an information carrier. The computer program product contains instructions that, when executed, perform one or more methods, such as those described above. The information carrier is a computer- or machine-readable medium, such as the memory unit, expansion memory unit, memory on processor unit, or a propagated signal that may be received, for example, over WCDMA unit or WiFi or BlueTooth units or external interface. Computing device may communicate wirelessly through communication interfaces such as WCDMA, WiFi or BlueTooth, which may include digital signal processing circuitry where necessary. Communication interface units may provide for communications under various modes or protocols, such as GSM voice calls, SMS, EMS, or MMS messaging, CDMA, TDMA, PDC, WCDMA, CDMA2000, GPRS, WiMax or LTE among others, although the example is based on WCDMA (UMTS). Such communication may occur, for example, through WCDMA unit. In addition, short-range communication may occur, such as using a Bluetooth, WiFi, or other such transceiver (not shown). In addition, GPS (Global Positioning System) unit may provide additional navigation- and location-related wireless data to computing device, which may be used as appropriate by applications running on device in the background or foreground. Computing device may also communicate audibly using audio codec unit (not shown), which may receive spoken information from a user and convert it to usable digital information. Audio codec unit may likewise generate audible sound for a user, such as through a speaker, e.g., in a handset of device 950. Such sound may include sound from voice telephone calls, may include recorded sound (e.g., voice messages, music files, etc.) and may also include sound generated by applications operating on the computing device. The computing device has an accelerometer unit that is used by the processor unit to find out the orientation and dynamic handling of the computing device. The computing device may be implemented in a number of different forms, as shown in the figure 2. For example, it may be implemented as a cellular telephone. It may also be implemented as part of a Smartphone, personal digital assistant, or other similar mobile device. [0027] There are two approaches to realize the novel idea disclosed here, I) Network Based method and II) Stand alone method. In the "Network based" method, the solution is embedded within a given cellular operator network (PLMN) and is operated by the operator itself. In the "stand alone" method, the solution is outside an operator's network (PLMN) and is operated by a third party. NETWORK-BASED METHOD

[0028] As an example of the "Network-based" method, a block diagram is shown in Figure 3. It must be noted that Figure 3 is one example in which the novel idea can be realized. There may be other network permutations that can also support the disclosed invention here. Figure 3 is a simplified version of the network shown in Figure 1 , with only the logical network connection shown. In the "Network based" model, a new application server called "Traffic Report Analysis Server" (TRAS) is connected to SMSC. TRAS is also connected to a database and storage unit called "Traffic Report DataBase" (TRDB). The TRDB is also connected to another server which is called "Traffic Report Gateway Server" (TRGS), which in turn is connected to SGSN. The SMSC, TRAS, TRDB and TRGS all belong to the same PLMN. In Figure 3, UE is a G1 Smartphone from Google which now has an additional new application software, called "Traffic Monitoring Application Program" (TMAP) stored in its memory unit. TMAP can be downloaded into UE via the WCDMA unit (i.e. over the air), or from the web, from the operators website via wireline or wireless internet, or by proximity to a server device via the Bluetooth unit. It can alternatively be placed in the UE memory unit at the operators' shop or at the time of manufacture by the manufacturer or in an expansion memory unit inserted later.

[0029] TRAS is made up of at least two SW blocks, called "TRAS Control Program" and TRAS Analysis Program" and performs, amongst other things, the following tasks:

[0030] Initiates "Traffic Report Request" instruction, by broadcasting a SMS (SMS-BC) message in a forward-and-forget mode in a given cell or paging or geographical area (via other network elements such as SMSC, MSC, RNC, NodeB etc).

[0031] Receives and stores "Traffic Report Responses" from the subscribers (via other network elements such as SMSC, MSC, RNC, NodeB etc).

[0032] Processes and stores in the database the Traffic Report analysis results.

[0033] Builds a history of the traffic behavior of the road segments in a region as function of hours, days of the week, months and years.

[0034] The Task of TRGS is to process the results generated by TRAS and stored on TRDB for delivery as content to customers and subscribers. It may be possible to use commercially available software for TRGS, providing the interfaces are modified to handle the data transfer between TRDB and TRGS. TRGS can provide information such as Traffic speed map and traffic congestion map for a given area, as well as providing traffic alerts on geographical bases. [0035] TMAP is made of at least three software blocks called, "UE Traffic Report Program", "UE Mobility Identification Program" and "UE Speed Estimation Program", and performs, amongst other things, the following tasks:

[0036] Runs timers to operate in a discontinuous mode (Sleep mode)

[0037] Identifies UE mobility type (i.e. Stationary (ST), Pedestrian (WK), Bicycle (Bl), Motorbike (MB) or Vehicle (VK)).

[0038] Estimates mobile maximum and average speeds (V _max and V _ave ), steady state speed (Vss) if any, UE average and maximum accelerations (a _ave and a _max ), position of the UE( x, , y,-), UE direction of travel (d) and time (f,).

[0039] Reports the estimations to TRAS by SMS (via other network elements).

[0040] Now, by way of an example and use of flowchart, the operation of the TRAS is explained. It is assumed that TRAS sends "Traffic Report Responses", via SMSC, for a geographical location. The size of this geographical location is determined by SMSC and TRAS processing capabilities. The same TRAS can send "Traffic Report Responses" to different geographical locations, which may include one or more NodeBs. It is also assumed before entering and starting a TRAS program, all flags and scratch registers and variables are cleared and "unset".

[0041] After starting (101 ) the program "TRAS Control Program" (100 in Figure 13), a timer t1 is set to P (102). The value of P determines how often the UEs (Smartphones) in the given geographical area are sent the "Traffic Report Request". This choice of the P value depends on how often an operator likes to update the traffic information, and how much signaling load overhead the operator is willing to accept. A value of 900 seconds (15 minutes) is reasonable and is assumed for the rest of this description. Once it is time for a "Traffic Report Request", "TRAS Control Program (100) sends a "Traffic Report Request" to all UEs in the defined geographical area, via the broadcast SMS (SMS-BC) in a forward-and-forget mode (105), for UEs (Smartphones) with "vehicular" mobility type (VK). That is, TRAS is requesting the UEs (Smartphones) that detected their mobility to be of the "vehicle" type, to respond to the request for traffic report. At this point, the timer t2 is set (106), to allow sufficient time to elapse for UEs with (VK) mobility type, to gather and report back to TRAS the required data. A reasonable example for t2 is 300 seconds (5 minutes). During this time, all "Traffic Report Responses" from UEs with (VK) mobility type are received, counted and stored in memory or disk (107) by "TRAS Control Program". Once the time of timer t2 is finished, the received and stored data is passed to "TRAS Analysis Program" (200 in Fig. 14) for further analysis (1 10). After which, "TRAS Control Program" (100) sends a "Traffic Report Request" to all UEs in the same geographical area, via the broadcast SMS (SMS-BC) in a forward-and-forget mode (1 11 ), this time for UEs (Smartphones) with "stationary" mobility type (ST). The timer t2 is set again (1 12), to allow sufficient time to elapse for UEs with (ST) mobility type to gather and report back the required information. During this time, all "Traffic Report Responses" from UEs with (ST) type mobility are received, counted and stored in memory (1 13) by "TRAS Control Program". Once the time of timer t2 is finished, the received and stored data is passed to "TRAS Analysis Program" (200) for further analysis (116).This can be the same or a different substantiation of the previous "TRAS Analysis Program" (200), working in data from UEs with (VK) mobility type. At this point, "TRAS Control Program" will set timer t1 to P (102) and wait for the time to send the next round of "Traffic Report Request" for updates.

[0042] Once the "TRAS Analysis Program" (200) is entered (1 10) with the "Traffic Report Responses" from UEs with (VK) mobility type, "TRAS Analysis Program" (200) will enter the vehicle (VK) branch of the process (203). "TRAS Analysis Program" (200) will sort all received data in the geographical region into street segments and direction, based on the final position of the mobile (X _f , Y _f ) and direction of travel (d), reported in the "Traffic Report Responses" (204). The street segment size is arbitrary, depending on the grid complexity, expected traffic level and street topology and the required accuracy of the analysis. For example, where the geographical region contains only a few highways, the highway segments can be defined as a 1000km stretches, while in a highly urbanized area, the segments may be defined every 50 meters. The reported average speeds (V _ave ) in each segment are used to form a histogram of all possible speeds, from stationary, to the maximum expected speed in the segment (205) for all directions (d). The granularity of the histogram bins depends on the expected traffic level and the required accuracy of the results. It also depends on the number of occurrences in each bin and the total number of "Traffic Report Responses".

[0043] Figures 4 and 5 show examples of highway and dense-urban street segment histograms, respectively. While the bins for the highway segment histogram maybe set to 10 mph granularity, the dense-urban street segments can be set to 5 mph granularity. Further, the histogram can be truncated (as shown in figures 4 & 5), to reduce the estimation range and to exclude erroneous reports.

[0044] It is possible that there is a grid-lock (traffic jam) in a segment, and all UEs are stationary. In such a scenario, the "Traffic Report Responses" for "vehicular" type (VK) will most probably not yield any responses from UEs, as UEs identify their mobility type as "stationary" (ST). To identify such a case, the "mode" bin of the histogram (i.e. the bin with most number of occurrences) can be examined for the number of reports (occurrences). If the number of UE reports (occurrences) in the "Mode" bin does not meet a minimum required level (which can be location dependant), (say 3 reports in a busy area), then the possibility of a grid-lock exists in that segment. So "TRAS Analysis Program" (200) can test to see if the minimum numbers of reports in the "Mode" bins will meet the minimum required for the segment (206). If the minimum threshold number is not reached, a flag ("Grid-Lock" flag) is "set" for the segment (207, 208), indicating a possible grid-lock in the segment. This operation (206) is carried out for all segments.

[0045] After the identification of all possible grid-locks, the histogram of the remaining segments is used to estimate the possible average speeds (say for different lanes) in every direction (209) of the given segment, followed by the calculation of the over-all arithmetic mean of speeds (or weighted mean or selection of one of the speeds) for each segment and the reported direction (210) . Subsequently, the history of the average speed (V _ave ) and the number of reports (# VK) are updated by the latest results (21 1 ). All estimated variables such as V _ave and time of day and the constructed histograms of all segments are stored on TRDB (212).

[0046] Once the "TRAS Analysis Program" (200) is entered (110) with "Traffic Report Responses" from UEs with (ST) mobility type as input, "TRAS Analysis Program" (200) will enter the Stationary (ST) branch of the process (203). "TRAS Analysis Program" (200) will sort all received data in the same geographical region into, preferably the same, street segments based on the final position of the UE ( , , Y _f ) reported in the "Traffic Report Responses" (213). The street segment size is arbitrary, depending on the complexity of the grid, expected traffic level and street topology and the required accuracy of the results. However, it is recommended to keep the segment choices similar to the one used in VK branch at (204). The accuracy of GPS data varies from a few centimeters to tens of meters depending on the satellites visibility at the GPS receiver. Also, if A-GPS is used, this accuracy is increased and improved considerably. Based on the segment topography, an expected GPS accuracy can be estimated. This estimation, along with the street size, can make the "Traffic Report Responses" from the UEs in certain regions of the segment (e.g. UEs with (X _f , Y _f ) near the centre of the street) more reliable and "credible" than the report from other UEs. These UE's are identified and selected for further analysis (214). If even a single "grid-lock" flag is set, the program enters the grid-lock verification branch (215). In this branch, the segments with "Grid-lock" flag as "set" are selected one by one (216) and are examined by looking for ST mobility type reports from above mentioned reliable and "credible" UEs (e.g. UEs in the middle part of a street). If these reliable and "credible" UEs are UEs that report "stationary" (ST) mobility type (217), then the segment in the given direction can be declared "grid-locked". If no UE with reliable and "credible" coordinates report "stationary" (ST) mobility type, then the segment for the given direction is still declared as "grid-locked", if the number of UEs reporting "stationary" (ST) mobility type is higher than historic levels (stored in the TRDB) for the segment by a set level (Δ) (218). Otherwise, the segment is not declared "grid-locked" and the program proceeds to update the "Historic level" of the segment and the direction with the latest average number of "Traffic Report Responses" from UEs with "stationary" (ST) mobility type (225), before testing more segments (220) for "grid-lock". After testing all flagged segments for grid-lock, the program proceeds to store all the extracted information and results in TRDB (223) and stops (224).

[0047] On the other hand, if no "Grid-lock" flag is "set", the program proceeds to update the "Historic level" of each segment and each direction with the latest average number of "Traffic Report Responses" from UEs with "stationary" (ST) mobility type (222), before storing all the extracted information and results in TRDB (223) and stopping (224).

[0048] Now, by way of an example and flowchart, the operation of the TMAP is explained. It is assumed that the extraction and calculation of variables such as average and maximum speeds and accelerations and direction (heading) from two or more GPS (or AGPS) position fixes are understood by a person sufficiently skilled in the art, as these calculations are performed in most commercial GPS (or AGPS) devices. It is also assumed that the conversions of Latitude and Longitude from "Degrees, Minutes and Seconds" to "Decimal Degrees" are understood by a person sufficiently skilled in the art. In any case, sections titled "Velocity definition, 'Acceleration definition" and "Directions of Vectors definition" provide definition for the required variables and the textbook by Elliott D. KAPLAN, titled: "Understanding GPS principles and applications" (ISNB: 0-89006-793- 7) will provide additional information on the use of GPS system. Also, vector notation can be used to handle most of the computation performed on the GPS (or AGPS) fixes. It is also assumed before entering and starting a TMAP program, all flags and scratch registers and variables are cleared and "unset".

[0049] After the start of the program (301 ), "UE Traffic Report Program" (300 in Fig. 15) tests to see if a "Traffic Report Request" SMS message from TRAS has arrived (305). If no request has arrived, a timer t is set to K. The inclusion of this timer is optional, with its major task to preserve UE battery life. For example, K can be selected such that the program examines for the arrival of "Traffic Report Request" message every 60 seconds. Alternatively, the program can be initiated by an external timer, executing the program at set intervals, via one of the interrupt lines of the processor.

[0050] If a "Traffic Report Request" message had been issued in the past (say 60 second), UE Traffic Report Program" (300) will execute "UE Speed Estimation Program" (307). After execution of "UE Speed Estimation Program", "UE Traffic Report Program" (300) will examine the "completed" flag to confirm the successful execution of "UE Speed Estimation Program" to the end (308). If the "completed" flag is "set", the output of "UE Speed Estimation Program", which is now stored in memory or/and disk, which includes average speed (V _ave ), Steady state speed (ν _Μ ), direction (cr), final sample points (X _f , Y _f ), Mobility type (VK or ST) and the time of storage (f), is then packaged along with other required information and sent to TRAS by an SMS message, via network elements (309). This SMS message is called the "Traffic Report Responses". In either of the cases, with the "completed" flag "set" or "not set", the "UE Traffic Report Program" (300) sets the timer f to L (310). L can be similar to K, or it can be larger, to preserve more battery after a traffic reporting session. L can even be smaller than K, without any loss or major impact on the operation.

[0051] After entering the "UE Speed Estimation Program" (400 in Fig. 16), and starting the operation (401 ), the UE is instructed to acquire GPS (or AGPS) network (402). If GPS receiver in the UE is already operational, the program will preferably check to see the GPS (or AGPS) network has been acquired and data from GPS receiver is valid. On confirmation that GPS (or AGPS) network acquisition (403) is successful, the program proceeds to collect and store a small number (Λ/) of position fixes (x _n , y„ ) from GPS (or AGPS) receiver at regular time intervals (f _s ), say 10 samples at 10 seconds intervals (405). If GPS (or AGPS) network is not available, the program stops (404).

[0052] The initial small position sample batch (N) is used within the "UE Mobility Identification Program" which is executed after sample collection (406). After the identification of mobility type by "UE Mobility Identification Program", if the detected type does not match the type specified in the "Traffic Report Request" message, the program stops (408). If the detected type does match the type specified in the "Traffic Report Request" message, the program calculates the average speed (V _ave ) based on the N collected samples (409). If the calculated average speed (V _ave ) is larger than a minimum threshold speed (Vo,), say 50 mph, the program proceeds (410) to calculate the direction of the travel (d) (418).

[0053] Figure 6 shows an example profile of UE speed travelling in a fast vehicle, say on a highway. It is reasonable to assume that the speed between the 10 position samples (x _n , y _n ), collected within 90 seconds, is very steady (as shown in Figure 6). Any fluctuations can be attributed to road curvature and GPS errors. In such a case, it is not required to collect any additional samples. It is also reasonable to assume that the average speed (V _ave ) is similar to the "steady state speed" (V _ss ), where the UE speed is substantially constant for two or more samples. [0054] If UE average speed (V _ave ) is lower than the threshold speed (Vo,), the program proceeds to collect M position samples (M > N) with a longer observation time, so that a more comprehensive speed profile can be constructed. Figure 7 shows an example profile of a UE speed travelling in a slow vehicle, say on a dense-urban street. In the example shown in Figure 7, there are twice as many samples as the one shown in Figure 6, giving an observation time of around 180 seconds. However, the observation time can be selected to be longer, based on the initial speed estimation made from the initial N samples, as long as the observation time (+ the processing times) do not exceed the maximum allowed time for sending the "Traffic Report Responses". Therefore, it is possible to have a set of optimum M values for different initial speeds that can be selected based on the initial average speed (V _ave ) (41 1 ).

[0055] In the example shown in Figure 7, the vehicle has variable movements with repetitive pauses (stops) and speed changes. In such a case, it is preferred to have, as well as an average speed (V _ave ), a minimum "steady state" speed (V^ in Figure 7). While the average speed (V _ave ) shows the end-to-end speed, including all the stops and pauses, the steady state speed (V _ss ) shows the dynamic speed once the vehicle is in motion. After selecting the desired value for number of samples (M), the program proceeds to collect and store M samples of position fixes (x _m , y _m ) from GPS (or AGPS) receiver at regular intervals (f _s ), say 20 samples at 10 second intervals (412). An optional check similar to 403 can be included before sample collection (412) to ensure the availability of GPS (or AGPS) network.

[0056] So far, the description has assumed the vehicle is travelling on a substantially straight line, or near straight line (e.g. <10 degrees directional changes), as shown in Figure 8. While this is true for fast moving vehicles, it is not true for slow vehicles in the dense-urban street, especially if the observation time is increased. In a dense-urban area with low vehicle speeds, it is possible that a turning vehicle has similar speed as a vehicle moving on a straight line, causing errors in the reported speeds on segments near junctions. Therefore, it is desirable to exclude UEs that have gone through a turn, from sending "Traffic Report Responses".

[0057] To identify the motion trajectory, incremental direction estimation (Ad) is performed (413). That is, direction estimation is performed between each (or a subset of contiguous) samples, giving the travel direction between two (or the subset of contiguous) samples. These directions, or at least the first and the last ones, are then compared and if the direction variation is too large (>Ad _max which for example can be 20 degrees) (414), "UE Speed Estimation Program" stops (415) and "UE Traffic Report Program" refrains from sending a "Traffic Report Responses". Figure 8 and 9 show a subset of 5 samples used at the beginning and the end of the sample block to estimate the initial direction vector (dr ₀ ) and the final direction vector (dr _L ). These two direction vectors (dr ₀ & dr _L ) are then normalized with their magnitudes and used in a "Vector Dot Product" and "arccos" (cos ¹ ) operations to extract the angle between the two vectors (in radians), as shown in Figures 8 and 9.

[0058] If the vehicle is moving on a substantially straight line, the "UE Speed Estimation Program" (400) proceeds to calculate the average and steady-state speeds (V _{ave &} V _ss ) based on the larger M position samples (416, 417), followed by direction (d) measurement (418). The estimated and calculated and captured variables such as average speed ( V _ave ), Steady state speed ( V _ss ), direction (d), final sample points ( , Y _f ), Mobility type (VK or ST) and the time of storage (f) are all stored on memory or/and on disk (419), and the "completed" flag is "set" (420) before the "UE Speed Estimation Program" (400) stops (421 ).

[0059] On entry to "UE Mobility Identification Program" (500 in Fig. 17), maximum speed (V _max ), based on the captured and stored data, is measured (502). If the maximum speed is zero (or substantially near zero) (503), the UE mobility type is set to "stationary" (ST) (504). The UE mobility type (ST) is then stored (505) and program stops (506). If the speed is not zero (or substantially near zero), maximum speed (V _max ) is tested to see if it is below 2 m/s, which is the speed of a fast walking person (507). If the maximum speed is less than 2 m/s, the UE mobility type is set to "Walking" (WK) (509). The UE mobility type (WK) is then stored (510) and program stops (51 1 ). If the speed is not less than 2.0 m/s, average acceleration (a _ave ) is estimated (508). If the UE maximum speed (V _max ) is less than 7 m/s (average bicycle speed) or the average acceleration (a _ave ) is less than 2 m/s ² (512), then the UE mobility type is declared as "Bicycle" (Bl) (513) and is then stored (514) and program stops (515). If the maximum speed (V _max ) is higher than a bicycle or average acceleration (a _ave ) is higher than one possible with a bicycle, "UE Mobility Identification Program" (500) can proceed to test the UE to establish if it is a motorbike (MB) or "Vehicle" (VK). If the average acceleration (a _ave ) is between 2 and 7 m/s ² (516), UE mobility type is declared as "vehicle" (VK) (517) and stored (518), before program stops (519). However, if the average acceleration (a _ave ) is higher than 7 m/s ² (516), the UE mobility type is declared as "Motorbike" (MB) (520) and stored (521 ), before program stops (522).

[0060] It has to be noted that the algorithm discussed above for all TMAP programs is exemplary and by no means the optimum. For example, "UE Mobility Identification Program" can be improved considerably by inclusion of the following features: [0061] The "UE Mobility Identification Program" can be run several times, in the background, before a definite decision is made on the mobility type. By running the algorithm several times with fresh data, the mobility is examined in different scenarios, providing better estimates of maximum speed {V _max ) and average acceleration (a _ave ).

[0062] A confidence factor (CF) can be included in identification steps. The confidence factor CF can simply be a measure of the margin at every decision point. If the margin is low, confidence factor CF is also set low. If confidence factor CF does not reach a minimum desired level, either the UE can refrain from sending a "Traffic Report Responses", or can execute the "UE Mobility Identification Program" with fresh GPS (or AGPS) position samples, until the minimum confidence level is met.

[0063] The decision variables, mainly maximum speed (V _max ) and average acceleration (a _ave ), can be complemented by the measurements from UE accelerometer. Most Smarphones have an embedded accelerometer, which can be interrogated by the processor for instantaneous measurements of UE orientation and movement. A UE on a walking subscriber or a subscriber on a bicycle can have a different accelerometer reading signature to a UE in a vehicle or Motorbike. Further, a UE with a subscriber on a motorbike can have a different accelerometer signature reading to a UE with a subscriber in a vehicle. The differences can be used to improve the mobility identity detections.

[0064] Further, the following features can be included in the system design and programs to improve overall system performance (with reference to Figure 10 and 11 ):

[0065] The UE participation in the traffic reporting activity can be a based on the UE battery status. If the battery life of UE is measured to be short, the UE can switch "OFF" all programs related to traffic reporting activity, discussed above.

[0066] The sleep time of UE can be based on the previous level of traffic reporting activity. For example, a UE can be limited to only a few sessions of activity (discussed above) per day.

[0067] The activation of TMAP programs and subsequent transmission of "Traffic Report Responses" can be solicited (i.e. by a SMS-BC "Traffic Report Request") from network, or unsolicited, sent by the UE on regular bases to the network, without a "Traffic Report Request" from network (TRAS).

[0068] In case, in a busy geographical area, there are too many UEs responding with "Traffic Report Responses", resulting to system overload on the uplink, the following features can be included:

a. A random number generator in TMAP can generate a random number each time before the execution of "UE Traffic Report Program". On the instruction of TRAS, all UEs with "even" or "odd" (defined in the even-odd field figure 10) random numbers (or last digit of the random number) refrain from participation and hence transmission of "Traffic Report Responses". If halving the number of participating UEs is not sufficient, this process can take place twice or more, reducing the first half, yet by another half and so on.

b. There can be a reserved broadcast SMS message (SMS-BC) in a forward- and-forget mode defined, that instructs UEs to refrain from sending "Traffic Report Responses" (say a "Stop request"). On reception of this broadcast SMS message, the remaining UEs stop execution of any TMAP programs and refrain from transmitting "Traffic Report Responses".

[0069] A "random back-off' algorithm can be included in TMAP and executed before sending "Traffic Report Responses", avoiding instantaneous uplink SMS messages from participating UEs.

[0070] A field can be added to "Traffic Report Responses" SMS message to indicate the identity of the sender (UE Type in Figure 1 1 ). For example, the field can identify a public transport vehicle, with the route number (Type ID in Figure 11 ), so that the network can use the location and speed information to identify public transport users of the desired unit's expected time of arrival at a given destination.

[0071] The example provided above requested responses from "vehicle" (VK) and "Stationary" (ST) mobility type UEs. However, to construct a better picture of the traffic, it is also possible to include responses from other types of UE mobility types.

[0072] A SMS message has a header which is used for message delivery and 140 bytes of payload. While this payload is sufficient for the example used here, if higher payloads are required, "Long" or "concatenated" SMS message can be used. Figure 10 and 1 1 show examples of the required fields for "Traffic Report Request" and "Traffic Report Responses".

[0073] All the fields in Figure 10 have been discussed previously, except "TRAS identifier" field, which is optional and is used to identify TRAS messages, if required.

[0074] Similarly, all the fields in Figure 1 1 have been discussed previously, except "TMAP identifier" field, which is optional and is used to identify TMAP messages, if required.

STAND-ALONE METHOD [0075] Figure 12 shows the "Stand-alone" method block diagram. Figure 12 is a simplified version of the network shown in Figure 1 with only the logical network connection shown. The "Stand-alone" network elements and operation are substantially similar to the "Network based" elements and operations discussed above, with one major difference. The difference being, while TRAS in "Network based" method was part of the same PLMN that housed SMSC, it is now part of a different PLMN or network. In this set up, a SMSG (SMS gateway) is used to connect the SMSC servicing TRAS to other PLMN's SMSC. Further, now the services provided by TRGS are provided over IP- network, via GGSN and SGSN of UE PLMN.

VELOCITY DEFINITION

(from: http://hypertextbook.com/physics/)

[0076] What's the difference between two identical objects traveling at different speeds? Nearly everyone knows that the one moving faster (the one with the greater speed) will go farther than the one moving slower in the same amount of time. Either that or they'll tell you that the one moving faster will get where it's going before the slower one.

Whatever speed is, it involves both distance and time. "Faster" means either "farther" (greater distance) or "sooner" (less time). Doubling one's speed would mean doubling one's distance traveled in a given amount of time. Doubling one's speed would also mean halving the time required to travel a given distance. If you know a little about

mathematics, these statements are meaningful and useful. (The symbol v is used for speed because of the association between speed and velocity, which will be discussed shortly.)

• Speed is directly proportional to distance when time is constant: v S s (t constant)

• Speed is inversely proportional to time when distance is constant: v E3 Vt (s constant)

[0077] Combining these two rules together gives the definition of speed in symbolic form.

s

v = _ (Note: this is not the final definition.)

[0078] Don't like symbols? Well then, here's another way to define speed. Speed is the rate of change of distance with time.

[0079] In order to calculate the speed of an object we must know how far it's gone and how long it took to get there. "Farther" and "sooner" correspond to "faster". Let's say you drove a car from New York to Boston. The distance by road is roughly 300 km (200 miles). If the trip takes four hours, what was your speed? Applying the formula above gives ...

s 300 km

v = - ~ = 75 km/h

t 4 hour

[0080] This is the answer the equation gives us, but how right is it? Was 75 kph the speed of the car? Yes, of course it was ... Well, maybe, I guess ... No, it couldn't have been the speed. Unless you live in a world where cars have some kind of exceptional cruise control and traffic flows in some ideal manner your speed during this hypothetical journey must certainly have varied. Thus, the number calculated above is not the speed of the car, it's the average speed for the entire journey. In order to emphasize this point, the equation is sometimes modified as follows ...

As

v =

At [0081] The line over the v indicates an average or a mean and the Δ (delta) symbols indicate a change. This is the quantity we calculated for our hypothetical trip.

[0082] In contrast, a car's speedometer shows its instantaneous speed, that is, the speed determined over a very small interval of time— an instant. Ideally this interval should be as close to zero as possible, but in reality we are limited by the sensitivity of our measuring devices. Mentally, however, it is possible imagine calculating average speed over ever smaller time intervals until we have effectively calculated instantaneous speed. This idea is written symbolically as ...

lim As ds

At→0At ^~ di or, in the language of calculus speed is the first derivative of distance with respect to time.

[0083] If you haven't dealt with calculus, don't sweat this definition too much. There are other, simpler ways to find the instantaneous speed of a moving object. On a distance- time graph, speed corresponds to slope and thus the instantaneous speed of an object with non-constant speed can be found from the slope of a line tangent to its curve.

[0084] Speed and velocity are related in much the same way that distance and displacement are related. Speed is a scalar and velocity is a vector. Speed gets the symbol v (italic) and velocity gets the symbol v (boldface).

average ,. , instantaneous

v = As v = lim As = ds

— speed — — speed At→ ΟΔΓ dt

ΔΓ average lim ΔΓ dr instantaneous

v = v = =

At velocity Δί→ OAt dt velocity

ACCELERATION DEFINITION

(from: http://hypertextbook.com/physics/)

[0085] When the velocity of an object changes it is said to be accelerating or more formally acceleration is the rate of change of velocity with time.

[0086] In everyday English, the word acceleration is often used to describe a state of increasing speed. For many Americans, their only experience with acceleration comes from car ads. When a commercial shouts "zero to sixty in six point seven seconds" what they're saying here is that this particular car takes 6.7 s to reach a speed of 60 mph starting from a complete stop. This example illustrates acceleration as it is commonly understood, but acceleration in physics is much more than just increasing speed.

[0087] Any change in the velocity of an object results in an acceleration: increasing speed (what people usually mean when they say acceleration), decreasing speed (also called deceleration or retardation), or changing direction. Yes, that's right, a change in the direction of motion results in an acceleration even if the speed didn't change. That's because acceleration depends on the change in velocity and velocity is a vector quantity — one with both magnitude and direction. Thus, a falling apple accelerates, a car stopping at a traffic light accelerates, and an orbiting planet accelerates. Acceleration occurs anytime an object's speed increases, decreases, or changes direction.

[0088] Much like velocity, there are two kinds of acceleration: average and instantaneous. Average acceleration is measured over a "long" (that means measurable) time interval while instantaneous acceleration is measured over a "very small" (unbelievably short or infinitesimal) time interval. For each kind of acceleration, there's an equation ...

Δν average lim Δν dv cfr instantaneous

a =— a = — =— = _ _

At acceleration Δί-→0Δί dt dr acceleration [0089] For those of you familiar with calculus, check out the second equation, which states that acceleration is the first derivative of velocity with respect to time and the second derivative of displacement with respect to time. Or if you prefer, acceleration is the rate of change in velocity and also (since velocity is a change in displacement) the rate of change of the rate of change of displacement, units

[0090] Calculating acceleration involves dividing velocity by time— or in terms of units, dividing meters per second [m/s] by second [s]. Dividing distance by time twice is the same as dividing distance by the square of time. Thus the SI unit of acceleration is the meter per second squared.

DIRECTIONS OF VECTORS DEFINITION

(from: http://www.glenbrook.k12.il.us/gbssci/Phys/Class/vectors/u3H a.html) [0091] Vectors can be directed due East, due West, due South, and due North. But some vectors are directed northeast (at a 45 degree angle); and some vectors are even directed northeast, yet more north than east. Thus, there is a clear need for some form of a convention for identifying the direction of a vector which is not due East, due West, due South, or due North. There are a variety of conventions for describing the direction of any vector. The two conventions which will be discussed and used in this unit are described below:

The direction of a vector is often expressed as an angle of rotation of the vector about its "tail" from either east, west, north, or south. For example, a vector can be said to have a direction of 40 degrees North of West (meaning a vector pointing West has been rotated 40 degrees towards the northerly direction) of 65 degrees East of South (meaning a vector pointing South has been rotated 65 degrees towards the easterly direction).

The direction of a vector is often expressed as an counterclockwise angle of rotation of the vector about its "tail" from due East. Using this convention, a vector with a direction of 30 degrees is a vector which has been rotated 30 degrees in a counterclockwise direction relative to due east. A vector with a direction of 160 degrees is a vector which has been rotated 160 degrees in a counterclockwise direction relative to due east. A vector with a direction of 270 degrees is a vector which has been rotated 270 degrees in a counterclockwise direction relative to due east. This is one of the most common conventions for the direction of a vector and will be utilized throughout this unit.

[0092] Two illustrations of the second convention (discussed above) for identifying the direction of a vector are shown below.

40° counter-clockwise 240° counter-clockwise

[0093] Observe in the first example that the vector is said to have a direction of 40 degrees. You can think of this direction as follows: suppose a vector pointing East had its tail pinned down and then the vector was rotated an angle of 40 degrees in the clockwise direction. Observe in the second example that the vector is said to have a direction of 240 degrees. This means that the tail of the vector was pinned down and the vector was rotated an angle of 240 degrees in the counterclockwise direction beginning from due east. A rotation of 240 degrees is equivalent to rotating the vector through two quadrants (180 degrees) and then an additional 60 degrees into the third quadrant.

CITATION LIST Elliott D. KAPLAN "Understanding GPS principles and applications" (ISNB: 0-89006-793- 7)

http://hypertextbook.com/physics/

Combining Road and Vehicle Sensor Traffic Information (W2009/026162 A1)