AU2018354458A1 - Road traffic monitoring and notification system - Google Patents

Abstract

A traffic management system uses a network of traffic detecting apparatus distributed through the traffic network, such as at each traffic light and detects vehicle IDs of passing vehicles, such as by detecting Bluetooth addresses from Bluetooth transmissions, and sends capture messages back to a traffic network monitoring centre. The traffic network monitoring centre estimates travel times, excess delays and congestion, and sends traffic status messages to the traffic detecting apparatus. These broadcast the message, for example in a modified iBeacon frame, which is detected by mobile devices in passing vehicles, and an app running on the mobile device parses the traffic status message and generates traffic alerts and information messages to users, for example by outputting an audio representation of the message on the mobile device or vehicle audio system.

Description

ROAD TRAFFIC MONITORING AND NOTIFICATION SYSTEM

PRIORITY DOCUMENTS [0001] The present application claims priority from Australian Provisional Patent Application No. 2017904366 titled “ROAD TRAFFIC MONITORING AND NOTIFICATION SYSTEM” and filed on 27 October 2017, the content of which is hereby incorporated by reference in its entirety.

TECHNICAL FIELD [0002] The present disclosure relates to traffic management systems. In a particular form the present disclosure relates to a traffic management system for use in arterial road networks found throughout cities.

BACKGROUND [0003] In most cities the number of vehicles travelling through road transport networks has continued to grow, leading to increased congestion. In an attempt to manage the increased traffic, a range of traffic management systems have been developed. The first systems, such as the Sydney Coordinated Adaptive Traffic System (SCATS) operated at the level of an intersection and used loop sensors in the road to detect vehicles approaching an intersection. This data was used to make an estimate of the state of the intersection (or incoming traffic flows) and a controller attempted to optimise the light sequence to optimise traffic flow and delays. More recently SCATS and similar systems have been extended by linking adjacent intersections to increase traffic flow through a local region of the network or to include additional sensors such Bluetooth receivers to detect as fixed camera systems to detect and monitor traffic flows.

[0004] Numerous systems have been developed for freeways that can monitor speeds and detect incidents. However freeways are characterised by long road segments with few (or no) intersections and free-flowing traffic and so are not easily transferrable to normal arterial road networks found throughout cities. Further such freeway systems are often expensive and so the expenditure can only be warranted for critical segments of road infrastructure. As such, the monitoring of arterial road networks has generally been limited to the installation of CCTV cameras or via the congestion monitors such as loop sensors used in SCATS, and this information is fed back to a traffic monitoring centre.

[0005] Recently a prototype Bluetooth based travel time system was deployed integrated Bluetooth transceiver apparatus into SCATS boxes at intersections and configured to discover the 48 bit MAC addresses of nearby Bluetooth devices, such as headsets or car audio systems in vehicles passing through

WO 2019/079845

PCT/AU2018/000210 the intersection that are in discovery mode. Whilst smartphones can potentially be discovered, they are typically only in a discovery mode during a pairing process (ie when a user has actively gone to a settings page to pair with another device), and so in most cases smartphones are not discoverable in vehicles passing through an intersection. The system uses a discovery period of about 15 seconds, and once a 48 bit MAC address was found, this was time stamped, and a message comprising the MAC address, time, and site ID was sent back to the traffic monitoring centre using the SCATS network link. This data was then used for planning and real time analysis of traffic flows to allow operators at the traffic monitoring centre to monitor congestion and adjust intersections to improve traffic flow through the network. Whilst this system has provided proof of concept, the Bluetooth receivers are only able to capture about 15% of the entire vehicle traffic passing through an intersection, and are typically located at one comer of an intersection which can limit detection. In particular the lack of data limited estimation of origindestination travel times. This thus limits the reliability and usefulness of the system. Further the system was designed for collecting data for use by operators in a traffic monitoring centre or traffic planners, and was not designed for notifying road users of congestion or delays.

[0006] There is thus a need to provide an improved road traffic monitoring system, or a useful alternative to present systems.

SUMMARY [0007] According to a first aspect, there is provided a method for monitoring traffic in a road traffic network comprising:

detecting, by a sensor in one of plurality of traffic monitoring apparatus, a vehicle identifier (ID) associated with a vehicle passing by or near to the traffic monitoring apparatus Bluetooth transmission of a nearby Bluetooth enabled devices, wherein the plurality of traffic monitoring apparatus are each located at a fixed site location in a traffic network;

sending, by a traffic monitoring apparatus, a capture message to a traffic network monitoring centre, the capture message comprising a site ID for the traffic monitoring apparatus; a representation of the vehicle ID, and a timestamp;

processing, by the traffic network monitoring centre, a plurality of capture messages to determine a link travel time for a link defined by two traffic monitoring apparatus, and obtaining an estimate of an excess delay and a congestion for each link, and one or more incident sites;

generating a plurality of traffic status messages, wherein each traffic status message has a traffic status message type and is generated according to a message format associated with the traffic status message type, and comprising the traffic status message type and a representation of at least one of the estimated link travel times, excess delay, congestion, and/or the incident site in the one or more message status fields;

transmitting each traffic status message to one or more of the traffic monitoring apparatus;

WO 2019/079845

PCT/AU2018/000210 broadcasting, by each traffic monitoring apparatus that receives a traffic status message from the traffic network monitoring centre, a beacon message comprising the traffic status message using a Bluetooth transmitter; and listening, by a plurality of traffic status listener apps each executed on a user device, for a beacon message, wherein each traffic status listener app comprises a message database comprising a plurality of site records each comprising a site ID and the associated site location for each traffic monitoring apparatus in the traffic network, and a plurality of traffic status message types and associated message formats, wherein each message format comprises a traffic status message type field and one or more message status fields, and on receiving a beacon message, processing the beacon message by extracting the traffic status message type and parsing the traffic status message using the message format associated with the extracted traffic status message type to obtain the value in each message status field, and providing a representation of one or more of the values obtained from the processed beacon message to a user via the user device.

[0008] In one form the sensor is a Bluetooth receiver, and detecting a vehicle identifier (ID) associated with a vehicle passing by or near to the traffic monitoring apparatus comprises detecting one or more Bluetooth transmissions from a nearby Bluetooth enabled device, and extracting a Bluetooth address from each received Bluetooth transmission, and using the Bluetooth address as the vehicle ID. In one form the beacon message is transmitted in an iBeacon message format comprising a 16 byte UUID field, a 2 byte Major field and a 2 byte Minor field, and a locality is transmitted or encoded in the UUID field, and each traffic status message is a 32 bit message in which the first 16 bits are transmitted in the 2 byte Major field and the last 16 bits are transmitted in the 2 byte Minor field. The site ID may be stored in a field in the traffic status message. In further forms, the traffic status messages comprise incident delay messages, multiple incident delay messages, information messages, travel time messages, each containing dynamically generated content regarding incidents, delays, congestion, travel time, or other messages which can be provided to users via the traffic status app, such as by using a text to speech engine to generate an the audio representation which can be played on a user’s mobile phone or vehicle audio system. In one form the traffic network monitoring centre is configured to merge incidents. In one form traffic status app generates historical trip logs which can be used to determine whether a user is likely to travel to a detected incident or to alert the user at the start of a trip if there is likely to be an excess delay on the trip.

[0009] According to a second aspect, there is provided a traffic monitoring system comprising:

a traffic network monitoring centre comprising one or more processor and one or more memories operatively coupled to the one or more processors;

WO 2019/079845

PCT/AU2018/000210 a plurality of traffic monitoring apparatus each comprising a Bluetooth transmitter, a sensor configured to detect a vehicle identifier (ID) associated with a vehicle passing by or near to the traffic monitoring apparatus, a communications module configured to establish a communication link with the traffic network monitoring centre, a memory configured to store at least a site ID and a processor operatively coupled to the memory, wherein each traffic monitoring apparatus is located at a fixed site location in a traffic network;

a plurality of traffic status listener apps which, in use, is configured to execute on a user device comprising at least one processor and a memory, wherein the memory comprises a message database, wherein the traffic network monitoring centre, the plurality of traffic monitoring apparatus, and the plurality of traffic status listener apps are configured to implement the method of the first aspect.

[0010] According to a third aspect, there is provided a traffic monitoring apparatus comprising a Bluetooth transmitter, a sensor configured to detect a vehicle identifier (ID) associated with a vehicle passing by or near to the traffic monitoring apparatus, a communications module configured to establish a communication link with the traffic network monitoring centre, a memory configured to store at least a site ID and a processor operatively coupled to the memory and configured to send a capture message to the traffic network monitoring centre, the capture message comprising the site ID; a representation of the vehicle ID, and a timestamp, and the memory is further configured to store a site ID, wherein traffic monitoring apparatus is configured to receive a traffic status message from the traffic network monitoring centre and to broadcast a beacon message using the Bluetooth transmitter, the beacon message comprising the site identifier and the traffic status message in an iBeacon message format comprising a 16 byte UUID field, a 2 byte Major field and a 2 byte Minor field, wherein a locality is transmitted or encoded in the UUID field, and each traffic status message is a 32 bit message in which the first 16 bits are transmitted in the 2 byte Major field and the last 16 bits are transmitted in the 2 byte Minor field.

[0011] In a further aspect, the sensor is a Bluetooth receiver configured to detect one or more Bluetooth transmissions from nearby Bluetooth enabled devices, and the traffic monitoring apparatus is configured to extract a Bluetooth address and to use the Bluetooth address as the vehicle ID. The Bluetooth receiver and Bluetooth transmitter may be combined in a Bluetooth transceiver. The traffic monitoring apparatus may be further configured to perform the steps of the method in the first aspect performed by one of the plurality of traffic monitoring apparatus.

[0012] According to a fourth aspect, there is provided a non-transitory computer program application configured to execute on a mobile computing apparatus, the non-transitory computer program application comprising a message database comprising a plurality of site records for a plurality of traffic monitoring apparatus in a traffic network, each site record comprising the site ID and the associated site location of a traffic monitoring apparatus, and a plurality of traffic status message types and associated message formats, wherein each message format comprises a traffic status message type field and one or more

WO 2019/079845

PCT/AU2018/000210 message status fields, and further configured to process a beacon message received by the mobile computing apparatus the non-transitory computer program application is executing on, wherein processing a beacon message comprises:

obtaining a traffic status message from the beacon message;

extracting the traffic status message type from the traffic status message and parsing the traffic status message using the message format associated with the extracted traffic status message type to obtain the value in each message status field; and providing a representation of one or more of the values obtained from the processed beacon message to a user via the mobile computing apparatus.

[0013] In a further form, the beacon message is an iBeacon message comprising a 16 byte UUID field, a 2 byte Major field and a 2 byte Minor field, and a locality is obtained from the UUID field, and the traffic status message is a 32 bit message obtained by joining the Major field and the Minor field and the site ID is obtained in a field in the traffic status message. In a further form the non-transitory computer program application is further configured to generate an audio representation by a text to speech engine, and to send the audio representation to one or more audio output devices either integrated with the mobile computing apparatus or connected to the mobile computing apparatus over a wired or wireless connection. In a further form the mobile computing apparatus is a mobile phone, and the mobile phone is connected to a vehicle audio system, and the one or more audio output devices are speakers in the vehicle connected to the vehicle audio system. In a further form the non-transitory computer program application is further configured to perform the steps of the method of the first aspect performed by one of the plurality of traffic status listener apps.

BRIEF DESCRIPTION OF DRAWINGS [0014] Embodiments of the present disclosure will be discussed with reference to the accompanying drawings wherein:

[0015] Figure 1A is a schematic drawing of a traffic monitoring system according to an embodiment;

[0016] Figure 1B is a map of a road traffic network according to an according to an embodiment;

[0017] Figure 1C is map of a portion of a road traffic network indicating the locations and site IDs of traffic monitoring Bluetooth transceiver apparatus, and road links showing excess congestion according to an embodiment;

[0018] Figure 1D is schematic drawing of a traffic monitoring system according to another embodiment;

WO 2019/079845

PCT/AU2018/000210 [0019] Figure 2A is a schematic diagram of a modified iBeacon message frame according to an embodiment;

[0020] Figure 2B is a schematic diagram of the network monitoring centre sending a message to a traffic monitoring Bluetooth transceiver apparatus for broadcasting as a modified iBeacon message, and the processing of a received modified iBeacon message by a traffic status listener apps according to an embodiment;

[0021] Figure 3 is a flowchart of a traffic status listener app processing a received modified iBeacon message from a traffic monitoring Bluetooth transceiver according to an embodiment; and [0022] Figure 4 is a schematic diagram of a return trip along the same road corridor in which a vehicle detours to a pickup site creating multiple detection records along the road corridor.

[0023] In the following description, like reference characters designate like or corresponding parts throughout the figures.

DESCRIPTION OF EMBODIMENTS [0024] Referring now to Figure 1 A, there is shown a schematic drawing of a traffic monitoring system 1 according to an embodiment. The system comprises a plurality of traffic monitoring apparatus 30 each located at a fixed site location 102 in a road traffic network 100, a traffic network monitoring centre 10, and a plurality of traffic status listener apps 20 which in use are configured to execute on user devices 22. These user devices may be mobile phones, tablets, laptops, and portable or mobile computing devices or apparatus including vehicle entertainment systems. The traffic monitoring apparatus 30 each comprise a Bluetooth transmitter and a sensor configured to detect a vehicle identifier (ID) associated with a vehicle passing by or near to the traffic monitoring apparatus. The traffic monitoring apparatus 30 further comprises a communications module configured to establish a communication link with the traffic network monitoring centre and is configured to send a capture message to the traffic network monitoring centre. Figure IB is a map of a road traffic network 100 showing major roads (minor roads and inner city roads have been omitted for clarity) and the locations 102 of traffic monitoring Bluetooth transceiver apparatus 30 (black dots) such as at traffic signals and pedestrian crossings, as well as the location 108 of a traffic network monitoring centre 10. In one embodiment traffic monitoring apparatus 30 are integrated into SCATS boxes located adjacent traffic signals or pedestrian crossings that provide power and a communications link back to the traffic network monitoring centre 10. The system may also comprise modular or stand-alone traffic monitoring apparatus 30 with a power supply and a network interface providing a network connection (eg 3G/4G/Wi-Fi/Wired) back to the traffic network monitoring centre 10 independent of SCATS boxes.

WO 2019/079845

PCT/AU2018/000210 [0025] Multiple implementations of the traffic monitoring system may implemented in different geographical regions or localities, and each network implementation may be assigned a locality (or implementation code) which uniquely identifies the network location. This can be included in transmissions to allow network entities to determine which network transmissions relate to, and thus how to decode messages and/or map codes to values using location specific mappings. Further this approach allows implementations to physically overlap, for example in cases where a state road network passes through a city road network, both of which are implementing separate networks.

[0026] Each traffic monitoring apparatus 30 is configured to store a site identifier (ID) 120 for its site location 102 and the traffic monitoring centre 10 stores the site identifiers and associated site locations 102 in a database 7. The traffic monitoring centre 10 and the traffic monitoring apparatus may also store the locality identifier ID for the network the entities are part of. The site IDs 120 and associated site locations 102 are also stored locally in a message database by each traffic status listener app 20. The site IDs 120 is a unique device identifier within the system such a unique name (eg BT69; BT93) or MAC address of the Bluetooth transceiver apparatus (or based on a MAC address), intersection identifier, SCATS box identifier, a geographic location (lat, Ion), or some other unique identifier. The site IDs are locally unique within the system, but may be reused in different localities.

[0027] The traffic monitoring apparatus 30 comprises a sensor configured to detect a vehicle identifier (ID) associated with a vehicle passing by or near to the traffic monitoring apparatus. In one embodiment the sensor is a Bluetooth receiver configured to detect Bluetooth transmissions of nearby Bluetooth enabled devices (field Bluetooth devices) - that is those within transmission range of the traffic monitoring Bluetooth transceiver apparatus 30. The transmission range is not an exact distance as it will depend upon factors such as transmitter power, receiver sensitivity and the local noise environment. For example this will include vehicles (cars, trucks, motor cycles, bicycles, etc) passing the Bluetooth receiver apparatus 30 (ie going through the intersection) containing Bluetooth devices (eg mobile phones, hands free kits, incar entertainment systems etc), as well as Bluetooth devices carried by pedestrians (mobile phones, headsets, etc) and any local static Bluetooth devices. In some embodiments the Bluetooth transmitter and Bluetooth transceiver are integrated into a Bluetooth transceiver. The traffic monitoring apparatus 30 extracts a Bluetooth address from each received transmission, which is used as the vehicle ID (or a proxy for the vehicle ID), and records a timestamp for the transmission such as the day and time to the nearest second. The vehicle ID and time stamp can be sent in a capture message to the traffic network monitoring centre 10 along with the site ID of the traffic monitoring apparatus. The locality can be included but is not required as the transmission is to another entity in the same network.

[0028] In some embodiments the traffic monitoring Bluetooth transceiver apparatus 30 enters a discovery mode for a discovery mode period to discover the MAC addresses of nearby Bluetooth devices. Only one record per MAC address is stored per discovery period, and as soon as a MAC address is found,

WO 2019/079845

PCT/AU2018/000210 the time stamp is recorded to the nearest second. In one embodiment a fifteen second discovery period was used as it provided a better indication of the arrival and departure times of each vehicle without creating an excessive number of records. In some embodiments traffic monitoring Bluetooth transceiver apparatus 30 is also configured to detect other Bluetooth transmissions (ie outside of discovery mode) by nearby devices. In one embodiment the traffic monitoring Bluetooth transceiver apparatus 30 is configured to detect paired Bluetooth communications and to extract the Lower Address Part (LAP) of a Bluetooth Device Address in a received transmission. The LAP is then used as the representation of the MAC address.

[0029] In another embodiment the sensor is configured to detect other broadcast identifiers used in other RF protocols operating in the 2.4GHz band. For example the antenna output, or RF front end output could be provided to a decoder module for another RF protocol (eg ZigBee or IEEE 802.15) which uses a clear unique device address in messages. Such an apparatus can be implemented in a software defined radio which receives the output of either the antenna or RF front end and performs multiple processing of the received signals - for example Bluetooth LAP detection, classic Bluetooth discovery, Bluetooth Low Energy (BLE) discovery , a Wi-Fi other RF protocols. Similarly a more hardware orientated apparatus could be used in which the output of the antenna or RF front end is provided to separate radio communications modules, each configured to detect a different RF protocol, for example to a Bluetooth LAP detection module, classic Bluetooth discovery module, a Bluetooth Low Energy (BLE) module, a Wi-Fi module and other decoder modules implementing RF protocols (or stacks). Some combination of the two could also be used. For example an apparatus with separate Wi-Fi and Bluetooth modules where the Bluetooth module could be configured to LAP in paired transmissions as well as classic and BLE devices in discovery mode. Similarly sensors operating in mobile phone spectrum (3G/4G/5G) could be used to detect the IMEI number of mobile phones in passing vehicles. In another embodiment the sensor could be a camera system which captures images of passing vehicles and an associated processing system is configured to use image analysis techniques to extract the number plate, or other unique characteristics of passing vehicles. In some embodiments the traffic monitoring apparatus comprises multiple sensors, such as a Bluetooth receiver (or transceiver) and a WiFi receiver.

[0030] To further illustrate the system embodiments will be described in which the sensor is a Bluetooth receiver, and in particular a Bluetooth receiver in a Bluetooth transceiver, and we will occasionally refer to the traffic monitoring apparatus as a traffic monitoring Bluetooth transceiver apparatus 30. Such an apparatus has advantages that the system is relatively compact, cheap, and Bluetooth is a widely used technology which is present in most mobile phone and vehicle audio systems. However it is to be understood that other sensor systems which can detect vehicle IDs could be used.

[0031] Once a message is detected a unique device address, or part of an address is obtained, a capture message 320 sent to the traffic monitoring centre 10 comprising the site ID; a representation of the

WO 2019/079845

PCT/AU2018/000210

Bluetooth address, and the timestamp. The representation of the Bluetooth address may be the 48 bit MAC address, a portion of the MAC such as the Lower Address Part (LAP), or an anonymised MAC address. An anonymised MAC address may be obtained by taking a hash of the MAC address and sending the hash or a part of the hash (eg last N bits) as the representation of the Bluetooth address. In one embodiment the capture message 320 is a 22 byte message. In some embodiments the traffic monitoring Bluetooth transceiver apparatus 30 stores the address of any local static Bluetooth devices and any transmissions identified as being transmitted from these devices are ignored or discarded.

[0032] The traffic network monitoring centre 10 comprises a plurality of software services installed on servers, databases, software applications for planning and real time reporting of traffic status, and interfaces for communicating with the traffic monitoring apparatus 30 and the traffic status listener apps 20. The network monitoring centre may comprise one or more processors and one or more memories operatively connected to the one or more processors for executing software codes or instructions, including software services and databases, and may be a single site, or a distributed system implemented in several locations, including cloud based implementations. The system may be implemented in various operating systems or programming languages. Figure 1A illustrates the various components of the traffic network monitoring centre 10.

[0033] The capture messages 320 are received from the plurality of traffic monitoring Bluetooth transceiver apparatus 30 via a network interface and processed by a live recording service 3 (for example a windows service application installed on a server). The live recording service 3 is configured to decode a received capture message, anonymise the representation of the Bluetooth address (eg the MAC address) if this was not already performed by the traffic monitoring Bluetooth transceiver apparatus. This is added to a real-time database 4 and paired with other records of same MAC address to get a device travel time through a link (or links) in the road traffic network.

[0034] The live processing service 5 processes or analyses the records in the real-time database 4 to generate site detection statistics, check the validity of new travel time records including removing outliers, and updates road segment aggregated travel times every 30 seconds. The live processing service may use other data such as SCATS lane count data or data from other sensors such as cameras feeds processed with automated license plate recognition software.

[0035] The live transfer service 6 moves data from temporary real-time database 4 to a primary database 8 (the Bluetooth and Detector Data Analysis Software or BADDAS S database) and vice versa. A collection of data processing services process the data stored in the real-time database 4 and primary database 8 and a user interface 9 provides real-time congestion information to network operators and allows data to be interrogated for planning studies using the processed results. A monitoring service 7

WO 2019/079845

PCT/AU2018/000210 monitors the status of the various services and restarts services as required (for example if they cease outputting data).

[0036] The collection of data processing services includes a SCATS VS Upload Service 11, SCATS History Upload Service 12, a Route Travel Time Calculation Service 13, a Link Travel Time Clustering Service 14, a Congestion Calculation Service 15, a Main Database Processing Service 16 and a Beacon service 17. The SCATS VS Upload Service 11 Reads SCATS “.VS” files (lane counts) and uploads data to database, the SCATS History Upload Service 12 reads SCATS “.hist files” (signal phase times) and uploads the data to database. Services can also be provided to load data from other sensor systems, such as automated licence plate recognition systems. The Main Database Processing Service 16 manages primary database tables and updates road segment aggregated travel times to create continuous 5-minute interval time series.

[0037] The Route Travel Time Calculation Service 13 joins live and historical travel time information for multiple road segments to predict route travel times and determines if route is operating worse than normal based on excess delay per kilometre.

[0038] The Link Travel Time Clustering Service 14 analyse up to 13 months of historic travel time data for each road segment to determine patterns (clusters). Each day can be divided into multiple periods and separately clustered. For example a day could be divided into 3 periods such as AM peak, PM peak and Business day, or clusters could be generated for each hour, half hour, or 10 or 15 minute period.

[0039] The Congestion Calculation Service 15 compares live travel times for each road segment against expected values from selected cluster time series and summarises key statistics for each road segment such as speed, delay, excess delay and congestion value. The service also determines if a road segment is operating worse than normal and generates network summary information for display on a reporting website.

[0040] Beacon service 17 manages messages transmitted by traffic monitoring Bluetooth transceiver apparatus 30 to traffic status listener apps 20. In some embodiments a modified iBeacon format is used such as shown in Figure 2A. The Beacon service 17 also identifies road segments that have abnormal congestion, activates traffic monitoring Bluetooth transceiver apparatus 30 to send traffic status messages 210 on the approaches to the congested road segments, and calculates the current total delay for each site approaching the congested segments.

[0041] The system 1 is configured to constantly monitor link travel times between adjacent traffic monitoring Bluetooth transceiver apparatus 30 and records the information as a continuous time series. The Clustering Service 15 runs daily to analyse the last 13 months of data to identify patterns in the time

WO 2019/079845

PCT/AU2018/000210 series data. The process automatically quarantines outliers such as excessive travel times caused by incidents. It automatically determines how many different clusters to create for each link depending on how much variation is present within the time series.

[0042] The clustering process compares the time series profile of road link (ie a road segment between two site locations (ie two traffic monitoring Bluetooth transceiver apparatus) for a target time period (for example AM peak on Mondays) against the same time period on other reference days. The other reference days may be just the same weekday (if sufficient data is available), or against every other week day, or even any other day. A similarity score or distance measure such as the Euclidean distance is calculated. A low Euclidean distance implies that the two days being compared are similar. Once this process is complete, the days with low Euclidean distance scores are placed next to each other and grouped into a dendogram of hierarchical clusters. The dendrogram is a tree-like structure that connects all of the days together based on their Euclidean distance, which is the value of the y-axis. Applying a threshold Euclidean distance cutoff cuts the dendrogram into a set of clusters. One of the key benefits of cluster analysis is that it requires no manual intervention to remove outliers, providing a robust way to forecast travel times in a real time traffic monitor. For example if today were a Wednesday, it would be acceptable to use the travel times from the previous few Wednesdays as a way of forecasting the travel times for today. However, this is not always the best approach if one of the previous Wednesdays was in the school holidays or affected by an incident. The clustering process takes care of this automatically so that the forecast travel times are based on typical Wednesdays.

[0043] The Congestion Calculation service 15 determines which cluster to use for comparison against live travel time data. The selection process takes into consideration factors such as the current day of the week and school and public holidays to determine the most appropriate cluster for comparison.

[0044] The Congestion Calculation service 15 outputs two key statistics every 30 seconds for each road link - Excess Delay and Congestion. Excess Delay is the difference between the live travel time and the expected travel time - that is the road links experiencing delays greater than normal. The expected travel time varies across the day and takes into consideration recurrent delays to only highlight abnormal congestion. This is obtained by pre-running a cluster analysis for each road link across a 13-month period to identify typical travel time profiles based on these same factors. A cluster selection algorithm then compares the features of the current day against the features of the clusters to identify which cluster to use.

[0045] The Congestion parameter is based on Excess Delay, but magnifies delays on short or reliable road sections and shrinks delays on long or highly variable road sections. The Congestion parameter takes the Excess Delay value and converts it to the number of standard deviations (effectively the t-statistic = (observed variationj/standard deviation). The standard deviation for a link also varies across the day, just

WO 2019/079845

PCT/AU2018/000210 like the travel time. During the middle of the day, most links typically have a small standard deviation of travel time because the travel time tends to be fairly consistent. Road links containing level crossings tend to have larger standard deviations because the travel time is less reliable, in particular during the peaks. This means that a highly variable link such as this will need a larger Excess Delay than a more consistent link to achieve the same Congestion value.

[0046] Delay information based on the estimated Excess Delay and Congestion parameters is output to users on a map of the network via a website or the using traffic status listener apps. The map only shows abnormal congestion - recurrent congestion does not appear on the map (as the clustering will identify this as the normal travel time for that day and time), so commuters can quickly check if there is a problem on their route to/from work. Figure 1C is a map of a portion of a road traffic network 100 indicating the locations and site IDs 120 of traffic monitoring Bluetooth transceiver apparatus 30, and road links showing excess congestion highlighted by colour coding according to an embodiment. As can be seen in this Figure there is congestion on link segment 111 between site IDs BT105 and BT 98, and congestion on adjacent link segment 112 between site IDs BT188 and BT 98. Heavy congestion is indicated on link 113 between site IDs BT3041 and BT69 by heavy black (originally orange) line. This congestion is reduced on link segment 114 between BT69 and BT93 shown in thin black line (originally light yellow), and is back to normal range on link segment 115 between BT93 and BT374. No highlighting is performed for road links with travel times within normal or acceptable ranges (for that day and time).

[0047] The Route Calculation Service uses a combination of live and historic data to predict the travel time along any road corridor. This allows travel times to be predicted on signalised arterial roads, not just freeways. The information can be sent to roadside variable message signs (eg displays) units to provide guidance to commuters about comparative travel times to selected destinations.

[0048] The Beacon Service automatically configures traffic monitoring Bluetooth transceiver apparatus 30 to warn passing motorists of approaching congestion. The system identifies unusual congestion, determines which approach devices to activate and automatically transmits real time delay information. The traffic monitoring Bluetooth transceiver apparatus 30 broadcast messages which are received by user devices 22 executing the traffic status listener app 20. The traffic status listener app 20 processes the messages and can be used to display the message or speak the message to a user using a text to speech engine. The app also determines if the vehicle is approaching the congestion and if so converts the beacon message into a descriptive warning message that is spoken by the phone’s text to speech engine. The app includes a local data base and does not require 3G or GPS to function, thus saving the phone battery. The traffic status message (Beacon) Service can also used to automatically trigger warning messages on variable message signs and other roadside displays.

WO 2019/079845

PCT/AU2018/000210 [0049] Figure ID shows schematic diagram of a system architecture according to another embodiment. In this embodiment a single data base 8 is used to store all data and the temporary real-time database 4 is eliminated or integrated into primary database 8, and the transfer service 6 is eliminated. A data retention service 141 monitors the database and removes duplicate records and other data as required. A message bus service 137 handles exchange of messages between the different services, an API based webserver 138 serves system data based on appropriate API requests. The API webserver also serves data to the user interface 9 and to client apps 22. An open data manager 134 also writes data from the database 8 to a local file share 135 which is synched with a cloud service 136. The data processing and calculation services are similar, with some services split and additional services added. The previous SCATS VS Upload Service 11, SCATS History Upload Service 12 are integrated into a single SCATS Importer service (or module) 132 which reads SCATS VS and Hist files from a filesharing site. As previously the data is clustered by clustering service 13 and a separate cluster scoring service 133 scores clusters for the current day and tomorrow. Link calculation service 13 determines the travel time of the links, and congestion service 14 determines congestion and excess travel times. An incident manager 139 detects incidents (eg excess delay or congestion) and in some embodiments identifies and merges related incidents. A route calculation service 140 calculates or stored predetermined routes between two or more devices. The Beacon manager 17 generates beacon messages which are send to the Bluetooth transceiver apparatus for broadcasting.

[0050] Figure 2A is a schematic diagram of a modified iBeacon message frame 200 used by traffic monitoring Bluetooth transceiver apparatus 30 according to an embodiment. The standard iBeacon message format comprises a 9 byte prefix 201, a 16 byte universally unique identifier (UUID) field of the beacon transmitter, a 2 byte major field 203, a 2 byte minor field 24 and 1 byte transmit (TX) power field 205. In traditional iBeacon usage the beacon is fixed and generates a static beacon message where the major field is used to identify a subset of beacons within a large group, for example all iBeacons at a particular shop (Woolworths), and the minor number identifying a specific region within that particular shop (eg deli section).

[0051] In contrast to traditional iBeacons, and as shown in Figure 2A, in the traffic management system the Major and Minor fields are redefined as a single 32bit traffic status message field 210 to define a dynamic broadcast beacon message. That is the iBeacon is a dynamic iBeacon, in which the Major and Minor fields contain dynamic content which can be parsed by the traffic status listener apps and used to provide information to users, The traffic status message field comprises a traffic status message field identifier 211 that defines the type of the traffic status message (212213214215216) each of which has a different format. The fields of each of the traffic status messages comprises message status codes with each code having an associated value such as an alphanumeric message string, a numeric value, or a parameter value. Traffic status messages may comprise the site ID of the transmitting beacon (the traffic

WO 2019/079845

PCT/AU2018/000210 monitoring Bluetooth transceiver apparatus 30). The locality may be stored in the UUID field, so that the combination of UUID and included site ID can be used to uniquely determine a site location. The traffic status listener apps comprises a message database that comprises the set of traffic status message field identifiers and associated message formats, as well as the mappings of the message status codes to the values. These formats and mappings are stored in a mapping database in the traffic status listener apps to enable them determine the type of the traffic status message and to decode a received traffic status message. Separate mapping databases may be used for each locality, or the mapping database may include locality information to ensure the correct records are identified (ie based on the locality).

[0052] This is further illustrated in Figure 2B. The traffic monitoring centre 10 selects type of traffic status message 210 from the set of traffic status messages known to the system to send to one or more traffic monitoring Bluetooth transceiver apparatus 30. The message is formatted with the relevant message status codes to encode information associated with the type of traffic status message to be sent, and this is sent to one or more traffic monitoring Bluetooth transceiver apparatus 30. Each traffic monitoring Bluetooth transceiver apparatus 30 that receives the traffic status message constructs a modified iBeacon message in which the UUID field 202 is the locality (or encodes the locality in a known way) of the traffic monitoring Bluetooth transceiver apparatus 30, and the major and minor field are replaced with the traffic status message 210, and this modified Beacon message is broadcast (transmitted) 221 to any listening Bluetooth devices. The site ID is included in the traffic status message, and together with the UUID can be used to determine the site location.

[0053] A user device 220 receives the modified iBeacon message via a Bluetooth communications interface 222. The traffic status listener app 226 checks the UUID field to determine the locality of the traffic monitoring Bluetooth transceiver apparatus 30 that transmitted the message. The traffic status message type field 210 is then extracted and processed. This comprises extracting the traffic status message field type (or identifier) 211 at the start of the message and looking up the message structure in message database 224. Once the structure of the traffic status message is determined, the codes or values in each message status field are extracted, such as the site ID of the traffic monitoring Bluetooth transceiver apparatus 30 that transmitted the iBeacon message. Any codes can be converted to associated values are obtained by the mappings stored in database 224 (which may use the locality information if included). A representation of the processed traffic status message is then generated for example using a text to speech engine, and provided to a user via a user interface 228 such as the device speaker, or another audio output device (either integrated with the user device or connected to the user device over a wired or wireless connection). A visual representation may also be provided, for example using icons or messages on a map displayed on the user device. In some embodiments the representations are audiovisual representations comprising audio messages and icons or coloured lines on a map.

WO 2019/079845

PCT/AU2018/000210 [0054] In one embodiment the traffic status messages comprises an incident delay message 212 in which the traffic status message field identifier 211 is 0 in bit 31; a multiple incident delay message 213 in which the traffic status message field identifier 211 is a 1 in bit 31, a 0 in bits 30 and 29; an information message 214 in which the traffic status message field identifier 211 is a 1 in bit 31, a 0 in bit 30 and a 1 in bit 29; a travel time message 215 in which the traffic status message field identifier 211 is a 1 in bit 31, a 1 in bit 30 and a 0 in bit 29; and a special beacon message 216 in which the traffic status message field identifier 211 is a 1 in bit 31, a 1 in bit 30 and a 1 in bit 29. Thus the initial bits (eg first three bits) form a traffic status message field which can be checked to enable the app to determine the traffic message type and thus the format of the remaining bits. Additional message formats could also be created. For example a multiple information message types could be defined.

[0055] Each traffic monitoring Bluetooth transceiver apparatus 30 can only broadcast one message, but each site can broadcast a different message, allowing a range of messages to be provided to users. The traffic network monitoring centre determines when to generate a traffic status message and which sites are to broadcast the message. This maybe in response to detected incidents such as travel time or congestion exceeding a predetermined threshold, or they may be scheduled or manually activated or deactivated by a system operator. Further the multiple incident delay message can be used to alert a user to multiple incidents, providing information on a first incident and allowing the app to establish a data connection back to the traffic network monitoring centre to obtain more detail on each incident.

[0056] A Schedule is defined by the following user settings: Days of the Week; Times of Day; Special Day Types and Specific Dates. A special day type is a customisable set of dates, and is used for School and Public Holidays (and other special dates). The dates corresponding to these special day types are defined in the system. A Schedule could be triggered to only run in the school holidays or conversely it could be set to only run when the current date is not in the school holidays. For example, to activate a broadcast for when school 40km/h zones are active, you would only want them to activate outside of the school holidays. Specific Dates can be used to activate or prevent a schedule activating on a particular date.

[0057] Messages can be assigned priorities to allow a traffic monitoring Bluetooth transceiver apparatus to determine what message to broadcast. By default incident messages (eg 212 213) are most important and will override a general information message (214) in the case of an incident. If messages have the same priority, the incident message will be broadcast, but the message will flag that a second message is available for download (ie the app can establish a data connection and download and parse any additional messages for the site). Travel Time broadcast messages (215) have the lowest default broadcast priority and will be overridden generally by information (214) and incident messages (212, 213).

WO 2019/079845

PCT/AU2018/000210 [0058] The following tables define the message formats. In these tables and the subsequent discussion, the traffic status message field identifier is referred to as Protocol Identifier, and traffic monitoring Bluetooth transceiver apparatus 30 are referred to as Beacons. These formats are stored by the user app. Additionally they can be provided in JSON or similar formats and made available for downloading from a webserver allowing dynamic updating of formats. In the following tables, beacon indexes are 12 bit site IDs.

TABLE 1

Incident delay message 212 (0..,) format.

<-High Bits to Low Bits->
Size	1 Bit	12 Bit	12 Bit	4 Bit	3 Bit
Bit No.	31	19-30	7-18	3-6	0-2
Description	Protocol Identifier	Current Beacon Index	Target Beacon Index	Incident Type	Delay Code
Value (s)	0	1-4095	0-4095	0-15	0-7

[0059] Incident messages are automatically managed by the system based on excess delay or congestion thresholds being exceeded. The message will tell the app where the user (or probe) device is (by looking up the site location of the current beacon index = site ID), where the problem is (the site location of the target beacon index), the cause of the delay (via the incident type) and the magnitude of the extra delay (via the delay code). The system will activate beacons on the approach to the problem (incident site) so that motorists have sufficient time to detour. The app will store mappings of incident type codes to incident type strings and delay codes to delay time ranges. These mappings can be provided as JSON files which can be downloaded by the app. For example in one embodiment the incident types json file is:

[{Id:0, Name/'Unknown}, {Id:l, Name:Roadworks}, {Id:2, Name:Long Term Roadworks}, {Id:3, Name:Collision}, {Id:4, Name:Burst Water Main}, {Id:5, Name:Road Closure}, (Id:6, Name:Hazard}, {Id:7, Name/’Event}, {Id:8, Name:Breakdown}, {ld:9, Name:Fire}, {ld:10, Name/'Traffic Signal Fault}, {Id: 11, Name:Level Crossing Fault}, {Id: 12, Name:Emergency Services Incident}, {Id:13, Name/’Flooding}, {Id:14, Name/’Incident}, {Id:15, Name/'Inclement Weather}, {Id:16, Name:Snow}, {Id: 17, Name/'Detour}, {Id:18, Name/'Blackout}]

WO 2019/079845

PCT/AU2018/000210 and the incident delay codes j son file is:

[{Id:0,MinDelay:120}, {Id:l,MinDelay:240}, {Id:2,MinDelay:360}, (Id:3,MinDelay:600), (Id:4,MinDelay:900}, {Id:5,MinDelay:1200}, {Id:6,MinDelay:1800}, {Id:7,MinDelay:2700}].

The delay codes represent the number of seconds of excess delay - the previous code value defines the minimum time and the current code value represents the maximum time (ie a code of 1 maps to 120 to 240 seconds).

TABLE 2

Multiple incident delay message 213 (100....)

<-High Bits to Low Bits A
Size	3 Bit	12 Bit	12 Bit	2 Bit	3 Bit
Bit No.	29-31	17-28	5-16	3-4	0-2
Description	Protocol Identifier	Current Beacon Index	Target Beacon Index	NOT USED	Delay Code
Value (s)	4	1-4095	0-4095	NOT USED	0-7

[0060] In situations where there is more than one message to be broadcast at the one site, perhaps for delays heading in different directions, the incident message will use the following protocol. To receive multiple messages will require an active data connection for the user app 20 to download the relevant messages. For mobile devices that have do not a data connection, they will still receive a message for the direction with the highest delay, but it will not include the reason for the delay. It will default to “Congestion - Unknown Cause” due to limits on the number of bits available.

[0061] Once this protocol is identified, the app should download data using a data request using the Current ID (current beacon index) as the filter. In one embodiment a “sites broadcasts)son” file contains all of the highest priority messages to be broadcast at every site. Table 3 shows a tabular representation of a sites_broadcasts.json file. A search is made for records in which the beaconindex field (of the sites broadcasts)son) matches the Current ID. If a match is found the object should contain 3 arrays Incident, Info and TravelTime. The details within each of these arrays should be converted into messages. Some arrays may contain zero, one or many messages of the same type. For each message the app will need to determine whether the user's direction of travel is relevant.

WO 2019/079845

PCT/AU2018/000210

TABLE 3

Table representation of “sites_broadcasts.json” file

SitelD	Beacon Index	Incident	Info	Travel Time
74	117	[{ LogTime:2018-0216T10:31:00+10:30, TargetSiteld :3037, IncidentType:O, ExcessDelay:120, DelayCode :0 }]	[{ LogTime:2018-02- 16T11:20:00.0748503+10 :30, DirectionType:0, Msgld:14, Broadcastld: }]	[]
207	120	[]	[]	[{ LogTime: 2018-0216T11:18:00+10:30, BroadcastTTDirectionld: 8, RouteOTT :395, Route ITT :462, Route2TT:870 }]

TABLE 4

Information message 214 (101....).

<-High Bits to Low Bits->
Size	3 Bit	12 Bit	4 Bit	13 Bit
Bit No.	29-31	17-28	13-16	0-12
Description	Protocol Identifier	Current Beacon Index	Direction Code	Message ID
Value (s)	5	1-4095	0-15	0-8191

WO 2019/079845

PCT/AU2018/000210 [0062] Up to 4095 sites can be used to broadcast dynamic information messages. These sites are network connected (same locations as incident messages) to allow their broadcast message to change between incident, information and travel time messages. The static messages are stored in the message database of the app so that they can be accessed when a data connection is not available. In one embodiment up to 8191 messages can be defined and broadcast by the app.

[0063] The Direction Code will define what direction of travel the message is applicable to. The values have the following meaning:

1) All directions

2) Northbound

3) Northeast bound

4) Eastbound

5) Southeast bound

6) Southbound

7) Southwest bound

8) Westbound

9) Northwest bound

10) Northbound and Southbound

11) Northeast bound and Southwest bound

12) Eastbound and Westbound

13) Southeast bound and Northwest bound

14) Location Marker Only (Trigger a check for messages on the cloud)

15) Silence App in Proximity (eg a beacon on a bus to turn off alerts)

16) Download Message [0064] If the Direction Code indicates a message should be downloaded (DirectionCode=15) or it is a location marker (DirectionCode=l 3), a data request should be used to retrieve the message using the Current Beacon Index. As outlined above the sites_broadcasts.json file (Table 3) contains all of the highest priority messages to be broadcast at every site. A search is made for records in which the beaconindex field (of the sites broadcasts)son) matches the Current ID. If a match is found the array assigned to the Info property should contain the actual Direction Code that is applicable and the Message Id of the message to spoken (or otherwise represented). If the app does not have this Message Id cached it will need to download the “beacon_messages.json file” and find the MsgText string assigned to the message with a matching Id field. Table 5 is a table representation of the “beacon_messages.json file”. The app will still need to determine whether the user's direction of travel is relevant based on the Direction Code in the sites_broadcasts.json file. Mobile devices that do not have a data connection will

WO 2019/079845

PCT/AU2018/000210 not hear any messages in these circumstances, even if the Message ID is defined. They only hear messages if the Direction Code is less than or equal to 12 and it matches their current direction of travel.

[0065] In one embodiment the app caches the message strings associated with the message IDs. The message format only allows 8191 messages to be defined within the broadcast message, so only these messages need to be cached. A situation may arise that warrants a customised message to be spoken. In this case, the message will not be included in the cached message set and will instead be retrieved from the web by requesting any messages available for the current site. The data returned will include the message string and the direction it is applicable to.

TABLE 5

Table representation of “beaconjnessages.json” file

ID	Category Name	MsgText	Repeat Interval	BroadcastID
350	Speed Reduction	Speed Reduced to 25 kilometres per hour ahead	120	225

TABLE 6

Travel time message215 (110....)

<-High Bits to Low BitsD
Size	3 Bit	12 Bit	2 Bit	5 Bit	5 Bit	5 Bit
Bit No.	29-31	17-28	15-16	10-14	5-9	0-4
Description	Protocol Identifier	Current Beacon Index	Direction Code	Destination Index 0 Travel Time Code	Destination Index 1 Travel Time Code	Destination Index 2 Travel Time Code
Value (s)	6	1-4095	0-3	0-31	0-31	0-31

[0066] Only network connected beacons with beacon indices less than 4096 will be able to broadcast travel time data. Typically, a site will broadcast incident messages as a first priority and will then fall back to travel time messages when the incident clears. For any given direction of travel (direction code 0-

3), a site will be able to have up to 3 destinations defined. The app will need to download and cache the

WO 2019/079845

PCT/AU2018/000210 information about the destinations defined for each site. These are called broadcast travel time directions. Each broadcast travel time direction will have a beacon index and direction. The broadcast_travel_time_directions.json file shown in table form in Table 7 file contains all of the defined travel time broadcast locations that are cached in the app. The app searches for the correct configuration by searching for the matching Current Beacon Index property and then the matching Direction Code property. This then tells the app what to speak when it describes Routes 0, 1 and 2. Determination of travel times between a site a destination can be determined using a shortest path algorithm which dynamically determines with the shortest path or route between the site and destination and looks up travel time for each link in this path. However in one embodiment each path between a site and a destination is predefined as a directed, or sequential, list of sites (eg represented as a linked list or similar data structure). For example in Figure IC the time to destination BT66 from BT1015 would be defined as (BT1015, BT98, BT207, BT66) This allows the travel time to be rapidly calculated by simply looking up the link travel time between successive links to obtain the total travel time to the destination. Such a calculation can be based on historical clustering data so that for longer journeys such as those spanning peak times, the travel time between later links in the path can be selected based on the expected time of arrival rather than the travel time for that link at the present time (which may change over time). This approach of using predefined routes substantially speeds up calculations of destination travel times and reduces the computational load on the system, as well as in the user app which can be configured to store the paths for each site destination pair.

TABLE 7

Table representation of “broadcast_travel_time_directions.json” file

ID	Site ID	Direction	Beacon Index	Routes
1	4054	SouthBound	120	Route ID	Name	Route ID	Name	Route ID	Name
13	Travel time to Stirling	201	to Mount Barker	202	to Murray Bridge

[0067] With reference to Table 6, using the broadcast values, the current beacon index and direction codes is retrieved, which can then be used to search the list of broadcast travel time directions to find the one relevant to that site and direction is performed. The broadcast travel time direction allows the string

WO 2019/079845

PCT/AU2018/000210 to describe each route to be retrieved. The broadcast message will contain the travel time codes for each route, which can then be converted to a travel time value in minutes.

[0068] The Direction Code will define what general direction of travel the message is applicable to. As there are only 4 options available, the Direction Code needs to use the closest bearing (± 45°) that is applicable. The values have the following meaning:

1) Northbound

2) Eastbound

3) Southbound

4) Westbound [0069] The Travel Time Code will convert into an approximate travel time in minutes. A site may not have all 3 destinations assigned, so these destinations will have a Travel Time Code = 0. The default values have the following meaning, but could be customised:

1) 0 = No Destination defined for this Destination Index or no data available

2) 1-10 = equivalent value in minutes (range=l-10 minutes)

3) 11-20 = 10 minutes plus 2 minutes per Travel Time Code increment above 10 (range=1230 minutes)

4) 21-26 = 30 minutes plus 5 minutes per Travel Time Code increment above 20 (range=3560 minutes)

5) 27-30 = 60 minutes plus 10 minutes per Travel Time Code increment above 26 (range=70-100 minutes)

6) 31 = >100 minutes

TABLE 8

Special beacon message 216(111....)

<-High Bits to Low Bils->
Size	3 Bit	29 Bit
Bit No.	29-31	0-28
Description	Protocol Identifier	Current ID
Value (s)	7	1-536870911

WO 2019/079845

PCT/AU2018/000210 [0070] This protocol is for beacons that do not change their broadcasted major and minor values. They will simply broadcast their unique Id. The app will store the message to speak for the beacon and in some cases beacons will have an option to request extra information from the cloud to check for any live messages. There are several use cases for these beacons:

• Emergency Vehicles - these beacons will not have coordinates set in the system. The app will simply identify that the beacon Id corresponds to a warning message of an approaching emergency vehicle or to tell motorists to slow down when passing a vehicle. Could also be used for school buses.

• Public Transport Vehicles - these beacons will have no coordinates and will be simply used to turn off spoken alerts when a user sits on a bus.

• Fixed Signs - these will have a location specified and they may contain a warning message to tell drivers to slow down for a curve / entering a township. These locations will be configured to get the app to check the cloud for any other non-default messages that are live for that location. They could also be used for more-permanent roadworks installations.

• Portable Signs - these will not have a location specified, but the message they broadcast generally need to be applicable to all directions of travel because there will be no way for the app to determine the user’s current direction without coordinates. These beacons will not get the app to check the cloud for extra information.

[0071] The mappings from the codes to value can be specifiedjson files or other similar formats (eg XML). This can be stored in traffic network monitoring centre 10 and either preloaded in the app or the app can dynamically obtained the file for the current network and parse the file. These can be general or default files or locality or implementation specific files, and these can be stored locally or downloaded and stored as required (eg as a new locality is entered). Separate files can be provided for each locality or a single file can provided with locality specific entries. For example the 7 incident delay codes could be stored in a file with 7 entries with, a category value (“id”: 0) and the associated value (“min delay”: 120). A locality identifier can also be included in the entry. Similarly the incident type json file contains 16 entries for the 16 incident types. Additional information can be included in entries, such as message expiry times or a repeat interval that defines the minimum time gap between the same message being spoken.

[0072] Destination travel times are directional, but a traffic monitoring Bluetooth transceiver apparatus will broadcast to vehicles travelling in any direction. In order to determine which direction to broadcast travel time information for, the system can be configure to either look at the current flow rate past the site in each direction and determine the direction with the largest flow rate, or histograms of historical flow rates indicating the highest volume direction can be used. The appropriate direction to broadcast travel times for can then be selected, and devices travelling in other directions can contact the webserver for

WO 2019/079845

PCT/AU2018/000210 other such directions. Alternatively a priority based system could be used, in which messages for the different directions are prioritised based on flow volumes so that travel times for high volume flows are broadcast more frequently can travel times for lower volume flows.

[0073] The traffic network monitoring centre 10 is configured to detect incidents and merge adjacent incidents. If the excess delay and/or congestion threshold is exceeded for a link an incident manager creates a new incident and determines the traffic monitoring Bluetooth transceiver apparatus at sites approaching the incident site by using the capture messages to determine the set of Bluetooth enabled devices which passed the new incident site within a predetermined time period prior to the incident, and identifying the previously passed sites for the set of Bluetooth enabled devices within a search time period. In this way a total count of the number of vehicles passing each previously passed site can be determined, and a volume filter can be applied to identify candidate sites. Then the shortest path to the incident link from the candidate sites is determined to create a branch of an n-ary tree of broadcast sites with the incident site at the head of the tree, and a maximum length filter is applied to each branch to prune the length.

[0074] Further when a new incident is created, the incident manager determines if the created incident is upstream of an existing incident, and detennines if the two incidents should be merged if either all of the links from the new incident to the incident site of the existing incident have excess delays greater than zero or the new incident site is on a trunk from the existing incident site, or if the new incident site is on a secondary branch and is within three levels of the existing incident site, and merges the newly created incident and the existing incident such that the new incident adopts the incident properties of the parent and the n-ary tree of the incident is added to the n-ary tree of the existing (parent) incident.

[0075] A link is defined as a one-way road segment that joins together two adjacent probe capture stations. Every 30 seconds an estimate of the live travel time for of each link is obtained, and this travel time is compared against the expected travel time from the link cluster analysis results. If the live data exceeds the expected data by a certain threshold, this will trigger the creation of an Incident. The Incident triggers are based on two parameters:

Excess Delay - Live Travel Time minus Expected Travel Time

Congestion Parameter - Excess Delay converted to a number of standard deviations from the Expected Standard Deviation [0076] By default the thresholds are set for all links and they can be modified by the local road authority to suit their conditions. The global settings can also be overridden for individual Links to have custom triggers levels. If a link does not have custom values set, it defaults to the global settings. In one embodiment 3 Incident trigger values defined, two of which are only used in combination:

WO 2019/079845

PCT/AU2018/000210

Excess Delay > X and Congestion > Y - the default settings for X and Y are 2 minutes and 5 respectively. This means that this trigger unless both conditions are met. A Link can have an Excess Delay of 5 minutes, but if it has a Congestion value less than 5 it will not trigger an Incident.

Congestion > Z - the default setting for Z is 12 and if a Link’s Congestion value exceeds this level an Incident will be triggered.

[0077] When an incident is triggered the IncidentManager service runs through the following steps:

[0078] Check that an incident is not already active on the Link. If so, no incident is created.

[0079] Determine how far upstream the Incident should broadcast. To do this, the algorithm runs a Select Link Analysis process on the link based on probes that traversed the link during the previous 30 minutes.

[0080] The process starts by creating a collection of Probes that meet the above condition. The algorithm stores the total number of Probes detected as MaxCount, which is used later to set thresholds.

[0081] It then iterates through each Probe and searches the past 2 hours of Probe travel time records to find where the Probe travelled prior to arriving at the current Link.

[0082] The algorithm counts how many times the probes visited each upstream Link and then runs through a process to only retain Links that meet the following configurable system criteria:

IncidentMinLinkCount (Default 30) - If an upstream link was traversed by more than 30 Probes, it is automatically retained as a broadcast Link. The subsequent criteria are not considered.

IncidentMinPercent (Default 25%) - The Probe count of the upstream Link is divided by the MaxCount of the Incident Link to determine if more than 25% of the Incident Link Probes traversed this Link.

IncidentMinPercentMinCount (Default 5) - To allow for the case where the MaxCount value is very small, the upstream Links needs to have been traversed by at least this number of probes. For example, if MaxCount was 4, the previous condition (IncidentMinPercent) would be satisfied with a count of 1 (1/4=25%), which is not a good representation of the general population.

[0083] The Select Link Analysis returns a list of potential broadcast Links. The algorithm then iterates each link through a shortest path algorithm based on a biased Dijkstra’s Algorithm to get the Links required to get from the subject Link to the Incident Link. If the shortest path contains links that were not identified through the Select Link Analysis, they are included in the list of broadcast Links. The Dijkstra’s Algorithm is biased because the network graph assumes a length of Im for all of the potential broadcast Links instead of their actual length, meaning that it will favour a route that uses these Links. The purpose of the shortest path process is to ensure that all of the broadcast locations have a complete

WO 2019/079845

PCT/AU2018/000210 path through to the incident Link. As it completes the shortest path for each Link, the sequence of Links is added to an n-ary tree of Links with the incident Link as the head node.

[0084] The n-ary tree of Links is then subjected to one final cull to ensure it is not broadcasting too far from the incident Link. There are three system-wide configurable parameters:

IncidentMaxNbLinks - (Default 10) - The n-ary tree can only broadcast this number of levels from the head node. This means the incident can only broadcast up to 10 links upstream.

IncidentMaxDistance - (Default 6000 metres) - The sum of the link distances through to the incident Link cannot exceed this value unless it meets the next condition.

IncidentMaxDistanceMinLinks - (Default 5) - Even if a link is more than IncidentMaxDistance from the incident Link, it can be retained if it is in the top 5 levels of the n-ary tree. This is to cover situations where the Links are higher speed and longer than typical signalised corridor Links.

[0085] The incident is finally created and assigned the n-ary tree of Links as its broadcast zone.

[0086] In some embodiments the system is further configured to merge a newly created incident with a downstream existing incident. This is performed as follows:

[0087] The incident Link is checked against the broadcast zones of the other active incidents to determine if it should merge. The algorithm iterates through all of the other incidents and performs the following checks:

[0088] Incidents that are not set to auto-expire based on delay are skipped. Incidents will only be automerged if they auto-expire.

[0089] The n-ary tree of the comparison incident is scanned to see if it contains the new incident Link. If it does, the following checks are done to determine if it is a merge candidate:

All of the Links from the new incident Link through to the head node of the comparison Link’s nary tree need to have Excess Delays > 0.

The new incident Link must be in the top 3 levels of the comparison incident’s n-ary tree if it is on a secondary branch on the tree. Alternatively, the Link is on the trunk of the n-ary tree it can be on any level.

[0090] When a merge candidate is found, the process to merge the incidents begins.

Firstly, the new incident is set as a child incident of the parent.

The new incident adopts the same properties as its parent - incident type and priority.

The n-ary tree of the parent is merged with the n-ary tree of the new incident to expand its broadcast coverage.

WO 2019/079845

PCT/AU2018/000210 [0091] Every 30 seconds, after the Link performance measures have been calculated, the IncidentManager will calculate the delays to broadcast for each incident that does not have a parent.

The process will iterate through each Link in the n-ary tree, starting at the head node. The Excess Delay of this head node Link equals its current Excess Delay. It then progresses iteratively through the levels of the n-ary tree, where the next level’s Excess Delay equals the previous level’s Excess Delay plus the current Link’s Excess Delay. This continues through to the lowest level of the tree.

The Excess Delay for each Link is then sent to BeaconManager to be broadcast from the Link’s origin Site.

[0092] Non-parent incidents are disabled when their Excess Delay drops below zero. If they belong to a parent incident, they are also removed from the parent incident. Parent incidents will not expire until all of the child incidents have been disabled. Once this has occurred, the incident can expire once its Excess Delay drops below zero. Incidents that have been set to expire at a particular time rather than automatically by Excess Delay follow the same process. The non-parent incidents expire if the current time is greater than their expiry time. If they have a parent, they are removed from the parent incident. Technically in this case, the parent must also be set to expire at this time because the parent and child share the same properties, but it can’t until its child incidents have all been disabled.

[0093] In one embodiment the app 20 can determine the user’s current direction of travel by passing two traffic monitoring Bluetooth transceiver apparatus sites and detecting the broadcast site identifier. This can then be converted to a site location using the mappings stored in the local database. In another embodiment when the app, via the phone’s motion sensor, detects that a user has started to drive, it will log the user’s current coordinates if location services is available. When the user gets to the first traffic monitoring Bluetooth transceiver apparatus 30 the app can then determine the direction of travel.

[0094] In one embodiment the app 20 will speak all messages that are relevant to the user’s direction of travel when they pass a broadcasting site. However in some cases the broadcast site may be several kilometres from the incident location and thus the alert may not be relevant even through their current direction of travel is towards the incident. For example, the user may only be travelling a short distance downstream or they may be changing direction (turning) to head onto a different route. Thus in one embodiment the app monitor’s the user’s travel patterns to provide more insight into the decision process. Every time the user’s phone detects driving mode, the app will start a new trip log. This will start by recording the Lat / Long from the phone’s location services if possible and store it against the current time.

[0095] For every beacon encountered, the app will log the ID of the beacon and the current time. Once driving mode has been expired for more than 5 minutes, the app will log the end Lat / Long against the current time minus 5 minutes. Once the trip is complete the app will clean the trip data to make sure it is

WO 2019/079845

PCT/AU2018/000210 complete and no sites were missed. To do this it uses a shortest path algorithm (Dijkstra’s Algorithm) using the first and last beacon site as the origin and destination respectively. It uses the intermediate sites detected to bias the shortest path algorithm along the actual route. Once a path has been found, the shortest path sites are used to determine the full set of Sites and Links traversed for the trip. This is then stored on the app device as a historical repository of trips. Once the user has made a few trips the app will be able to predict the likelihood that the user will pass through an incident location.

[0096] Figure 3 is a flowchart 300 of a traffic status listener app processing a received modified iBeacon message from a traffic monitoring Bluetooth transceiver according to an embodiment. At step 301, the app receives a broadcast message from traffic monitoring Bluetooth transceiver apparatus (beacon) with an incident site. The app determines if the user is heading towards the incident site 302. If not 304 then no alert is spoken 315. If the answer is yes 303 then the quality of historical site visit data already collected is assessed at 306. If the quality is poor then an alert is spoken to the user 315. If the quality is good 307 the app determines if the user has visited the current site before at the same time 309. If not the alert is spoken 316, but if so a test is performed to determine if the historical trip paths include the incident site location 312. If not 313 (ie the user is expected to turn off or stop before the incident) then no alert is spoken 315. However if the result is yes 314, then the alert is spoken 316 (as the user is expected to be heading to the incident). The quality can be assessed based on the number of repeated trips (ie at least 10), or a measure of variance, or similar quality measure.

[0097] The app can also pre-emptively report incidents based on historical trips. When driving mode has been detected, the app will search the historical trip repository to determine if a particular trip is likely to take place. If it finds a recurring origin - destination trip for the current day of the week and time of day, the app will attempt to download the latest performance statistics for the links that make up the trip route. This feed contains the travel time, delay and excess delay of every link on the network. It will then determine the total excess delay for the route and if it exceeds a user-defined threshold, the user will hear a pre-trip warning about delays to reach the destination site.

[0098] In the above discussion it is assumed that the flow rate in a road is the same in all lanes. However on multi-lane roads there can be instances where the flow rate varies on a lane by lane basis. Thus in one embodiment the system is configured to determine clusters, excess travel times and congestion parameters on a per lane basis. For example in a three lane road, an accident may shuts down an inner lane and cause congestion in the middle lane as the inner and middle lane merge. The outermost lane has access to side streets which allows vehicles to deviate and avoid the congestion generating an increased flow rate in the outermost lane. However detection of such effects is difficult, as the receivers are only detecting how long a vehicle takes to travel between two sites, and not the specific path or lane they used. The observed travel time data will thus have a wide distribution of times such as from 5 mins to 30 minutes. In such cases it is difficult to determine what is the correct travel time to use or broadcast, or

WO 2019/079845

PCT/AU2018/000210 whether this indicates an incident. For example, the distribution in times could be due to an incident in the inner lane or several cars may be stopping by the side of the road to make purchases from a roadside vendor or drive through. Alternatively an outer lane may be congested compared to an inner lane due to large number of vehicles wishing to turn off at a particular point (eg an off ramp or intersection).

[0099] One solution is to calculate a local outlier factor to identify whether points are simply outliers, or they are forming a distinct cluster. The local outlier factor for a data point A determines whether its Knearest neighbours also consider data point A to be their nearest neighbours. One analogy is that I may consider a set of people are all my good friends, but none of them consider I am their good friend. Mathematically the local density is calculated by determining a reachability distance for two points A and B as the maximum of either the true distance between objects A and B, and k-distance of B, where the kdistance is the distance to the k th nearest neighbour. The local reachability density is then the inverse of the average reachability distance of the object A from its neighbours. The local outlier factor is than the average local reachability density of the neighbours divided by the object's own local reachability density. A value of approximately 1 indicates that the object is comparable to its neighbours (and thus not an outlier). A value below 1 indicates a denser region (which would be an inlier), while values significantly larger than 1 indicate outliers. Applying this to the road traffic problem, the link travel times can be determined and a local outlier factor determined for each point. As the impact of an incident begins to delay travel times, the volume of traffic with delayed travel times will decrease and the data will separate into two (or more) clusters. That is travel time that was initially an outlier value will form a local cluster, as indicated by these travel times having smaller local outlier factors (ie decreasing to less than 1). One two distinct clusters are determined, the system can be configured to issue an incident warning, and broadcast multiple travel times for the route. Further by tracking the paths of vehicles entering the region, it may be possible to determine incoming routes that are more likely to face congestion, for example because they feed into the affected lane, and issue appropriate warnings on that route. One related problem is what travel time should be system use for the partially congested link. In one embodiment the size of a cluster (number of points) could be used as weighting factors, for example by counting the number of points with local outlier values of less than 1.

[00100] Another issue is that the travel times requires an accurate baseline cluster for comparison, and if the wrong baseline is used this may affect travel time estimates. For example in country roads a long weekend (holiday weekend) may generate significant excess traffic compared to other weekends. Thus in one embodiment days may be classified, and the system may be configured to weight the importance of different days and predict the cluster to use based on the classification of the day.

[00101] In one embodiment, each time a vehicle ID is detected at a site a search is performed for any previous records from the past hour that define a link segment. However this can generate erroneous records in the case of return trips within a short duration of time. For example a vehicle may travel to a

WO 2019/079845

PCT/AU2018/000210 drop-off/pick-up point such as a school or airport and then return along the same road corridor or path, multiple records can be created. In this case the Traffic monitoring Bluetooth transceiver apparatus 30 along the route will detect the vehicle twice (eg on the outbound and return leg) and create two records with different time stamps. If the route travel time calculation service 13 simply pairs site data this can create erroneous travel time records.

[00102] Figure 4 is a schematic diagram of a return trip along the same road corridor in which a vehicle detours to a pickup site creating multiple detection records along the road corridor. Traffic monitoring Bluetooth transceiver apparatus 30 located at sites A, B, C and D along the road corridor and detect a vehicle on outbound route 410 with a unique device ID (eg associated with a device in the vehicle). The vehicle passes points A, B, C, and D at times 0, 5, 10 and 15 minutes, and these detection are timestamps creating capture records 411,412, 413 and 414. At site D, the vehicle takes a detour 422 to a pick up point 424, which in this case is an airport. The vehicle then returns from the pickup point 424 along route 426 and reappears at point D. The vehicle then travels a return leg 430 passing sites D, C, B and A, at times 25, 30, 35 and 40 minutes. These detections are timestamped creating capture records 431,432, 433, 434 respectively. The travel time algorithm has two records for each link formed by an adjacent pair of sites along a direction of travel, giving two travel times for each link: 5 and 35 minutes for link AB; 5 and 25 minutes for link BC; 5 and 15 minutes for link CD; 5 and 15 for link DC; 5 and 25 for link CB; and 5 and 15 for link BA. The true travel times for each of links AB, BC, CD, DC, CB and BA should be 5 minutes. However if the system pairs simply pairs all records then there are also erroneous records created: 35 minutes for links AB and BA; 25 minutes for links BC and CB; 15 minutes for links CD and DC.

[00103] One approach would be to hold capture records for a site for one hour, and if, for a link, a vehicle ID is paired with more than one capture record then all records for that vehicle ID is deleted for that link. In another embodiment the progression of a vehicle through the network is monitored, and only the last n sites visited are kept as potential pairing candidates. As soon as a new record is paired with a historical record, all capture records for the vehicle that have a time older than the newly paired historical record are deleted. For example with reference to Figure 4 this approach would lead to correct travel times of 5 minutes for each of links AB, BC, CD, DC, CB, and BA. The value of n can be determined based on the network geography and density of the sites. In one embodiment n is between 5 and 10, such as a value of 5. In one embodiment n is determined based on trial data collected from the network. This could be performed during an implementation or obtained periodically, or as additional sites are added to the network.

[00104] In a further embodiment, rather than deleting all capture records for the vehicle that have a time older than the newly paired historical record, a short time period is added to prevent incorrect detections that can occur where there are multiple detectors in close proximity, such as at overpasses.

WO 2019/079845

PCT/AU2018/000210

This time period will typically be short such as between 1 minute and 3 minutes. For example for a link A to B, as soon as the new site B is paired to a historical site A, all capture records for the vehicle that have a time old than 2 minutes are deleted. For example in Figure 1C the link 111 from BT1015 to BT98 and link 112 from BT98 to BT188 is an underpass of the road from BT98 to BT207. If a vehicle is travelling along the underpass from BT188 to BT1015, it may be detected at site BT98 (for example to capture vehicles turning off towards BT207). In the previous embodiment the capture record for BT188 would be deleted once paired with BT98. By holding the data for BT188 for a short period of time after detection at BT98, such as 2 minutes, the vehicle ID is captured at true destination site BT1015, and this can be correctly paired with BT188 and BT98 can be ignored (ie no travel time recorded for BT188 to BT98).

[00105] The same logic would apply where 3 sites are in sequence A, B and C, where B is a new site that has been added and now splits the link AC into AB and BC. Until these new links have enough historical data for clustering, AC must be kept active and all 3 links need to have travel time records generated.

[00106] The above discussion describes application to a single road network (locality) with a single network monitoring centre. However the system can be used for multiple different road networks each with a separate network monitoring system, for example in different cities, or even in overlapping regions, for each where one authority controls state roads and another authority controls town roads. To allow the app to adjust to a user driving in several different road networks the database and functionality the app may store data at different hierarchies so common data is stored in one place, the same data for different systems can be stored in separate collections (ie different containers). For example, if a user customises their app in Adelaide to only hear certain information message categories, it may be that VicRoads are using completely different categories. The user may then configure the app for the Melbourne categories, but we don’t want the app to lose their Adelaide settings. This will not apply to all message types and some can be global settings. A unique locality code can be assigned to each network and may be included in transmissions, such in the UUID field of iBeacon transmissions to assist listening devices determine which network they are receiving a transmission from.

[00107] In one embodiment the following would be global settings:

Incident messages On / Off

Route travel time messages On / Off Information messages On / Off Pre-trip delay messages On / Off [00108] In one embodiment the following would be locality specific (ie road network specific) settings:

WO 2019/079845

PCT/AU2018/000210

Minimum delay for incident messages. The delay thresholds for each category will not be consistent between road authorities. VicRoads may choose to use higher thresholds, so category 2 in Adelaide could be equivalent to category 1 in Melbourne.

Specific categories of information messages On / Off. Although there may be some overlap with categories between road authorities, we have to assume that they will be different. You could store them as a single list of categories, but when displaying in the UI, only the ones relevant to the current location should be displayed otherwise you may end up with very similar categories in the list, which will confuse the user.

[00109] The following are some examples of downloaded data that will be different between road authorities (networks):

Incident Types - In one embodiment 15 incident types can be defined by the network operator, so incident type 5 in Adelaide might be “crash”, but in Melbourne it could be “roadworks” [00110] Incident Delay Categories - In one embodiment 8 delay thresholds can be defined by the network operator, so incident delay code 0 in Adelaide might be 2-4 minutes delay, but in Melbourne it could be 3-5 minutes delay.In one embodiment each locality is assigned a Primary UUID which is used to identify the locality and the 16 bit UUID may be mapped to short locality ID (or code). To simplify the logic associated with changing from one system locality to the next (eg changing state or going from ACT into NSW), there will be a feed of the UUIDs used for each road authority. Due to the limitations on the number of UUIDs allowed to be registered per app, UUIDs may be reused between different regions/implementations. This means that if the app detects a change of UUID, but the new UUID is not unique to one location, the app is triggered to get the phone’s current location. Preferably the systems would be configured to avoid reusing the same UUID for adjacent installations of the system (eg there would be no reuse between ACT and NSW) so the location services fall back should be able to determine the correct information to use. Further they could be made unique per country or continent. Table 9 provides an example of the format of UUIDs file in json format.

TABLE 9

Primary UUIDs format.

adj acent_i ds: [ 3, 7, 10, 5 ], bbox: [ 128.995, -38.055, 140.999, -25.999] beacon_uuids: {

7004719a-8902-4e34-aOcf-65e2a3a434bd: 3,

21703197-e4d8-4da6- bbf a-f 16a94c5b85b: 2 }, city: Adelaide,

WO 2019/079845

PCT/AU2018/000210 cont i nent: Aust r al i a, count ry: Aust ral i a, def aul t _l ocat i on: [ 138.6007, -34.9285 ], id: 2, owner: DPTI , st at e: Sout h Aust r al i a, ur I: ht t p: / / Uni queSt r i ng. cl oudf r ont. net I Sout hAust r al i a/ }, {

adj acent_i ds: [4, 8, 2, 7 ], bbox: [ 140.9387, -39.5147, 149.9891, -34.0145], beacon_uuids: { ff1df88b-966c-47ed-9ce1-72dff3c2a14c: 3 }, city: Melbourne, cont i nent: Aust r al i a, count ry: Aust ral i a, def aul t _l ocat i on: [ 144.96332, - 37.814 ], id: 3, owner: VicRoads, st at e: Vi ct or i a, ur I : ht t p: / / Uni queSt r i ng. cl oudf r ont. net / Vi ct or i a/

}] [00111] In the above table the UUID for the Version 3 South Australian network is

7004719a- 8902- 4e34- aOcf - 65e2a3a434bd which is assigned short hand locality ID 2, and the UUID for the Version 3 Victorian network is f f 1 df 88b- 966c- 47ed- 9ce1 72df f 3c2a14c which is assigned short hand locality ID 3. As networks, or network entities are upgraded, new UUIDs may be used to designate the new version. For example in the above Table, South Australia has two beacon UUIDs corresponding to version 2 and version 3 networks (each version implementing different functionality ). The adjacent ids lists the shorthand IDs of adjacent traffic management system implementations (ie which a user will transition to), the bbox defines a bounding box in map (lat, Ion) coordinates, and the beacon uuids lists the uuids for each version, and the remaining fields identify location information (city, continent, country, coordinates), the shorthand locality id, network owner, state and a url which can be used to obtain any locality specific configuration, information or mapping files eg in JSON or similar formats.

[00112] The UUIDs are stored by transceiver apparatus 30 and identifies which traffic network the apparatus is part of. For example each state, city or region will have a different UUID, so the user app can determine which traffic network it is within and receiving data from. The transceiver apparatus 30 further stores a locally unique site ID which identifies the location of the transceiver apparatus 30 within the current traffic network. That is, in some embodiments, the site ID may not be globally unique but is unique to the current traffic network, or at least unique to the current traffic network and any adjacent networks. In some embodiments site IDs could be unique to a country or continent. This allows site IDs

WO 2019/079845

PCT/AU2018/000210 to be reused between non adjacent road traffic networks or implementations, and reduces the number of bits required to store the site ID. For example 12 bit site ID can be used to identify 4095 sites. Transmissions can include the UUID of the locality and the site ID allowing a user app to uniquely determine the site location and appropriate database or mapping files for looking up or decoding coded data contained in a message. If a user app detects a change of UUID, this indicates the vehicle is now in a new traffic network, and the app is triggered to use the mapping database or files specific to the new location when looking up site IDs, and other network specific parameters. If these are not locally stored then a data connection can be established to the URL to download any required files or data. In an alternative embodiment location services could be used to obtain the phone’s current location to determine which traffic network it is within, however this incurs significant power costs, and is unreliable in the case of overlapping networks in built up areas.

[00113] One further advantage of the use of a locality UUID is that it permits geographically overlapping networks. Thus a state road network could pass through, and overlap with a city road network. As each beacon identifies the locality and the site ID, user apps (or other entities) receiving beacon messages can determine which network the transmission originated from, and thus correctly decode the information.

[00114] Various aspects of the system are computer implemented on computing devices comprising a processor ((eg CPU) and a memory and in some cases an input device and a display device. The memory may comprise instructions to cause the processor to execute a method described herein. The computing device may be a desktop computer, a portable computing device such as a laptop computer or tablet, smartphone, a server, including a cloud based service, or they may be included in a customised device. The computing devices may be unitary computing or programmable devices, or a distributed device comprising several components operatively (or functionally) connected via wired or wireless connections, including cloud based devices. The CPU may comprises an Input/Output Interface, an Arithmetic and Logic Unit (ALU) and a Control Unit and Program Counter element which is in communication with input and output devices (eg input device and display apparatus) through the Input/Output Interface. The Input/Output Interface may comprise a network interface and/or communications module for communicating with an equivalent communications module in another device using a predefined communications protocol (e.g. Bluetooth, Zigbee, IEEE 802.15, IEEE 802.11, TCP/IP, UDP, etc). A graphical processing unit (GPU) may also be included. The display apparatus may comprise a flat screen display (eg LCD, LED, plasma, touch screen, etc), a projector, CRT, etc. The computing device may comprise a single CPU (core) or multiple CPU’s (multiple core), or multiple processors. The computing device may use a parallel processor, a vector processor, or be a distributed computing device. The memory is operatively coupled to the processor(s) and may comprise RAM and ROM components, and may be provided within or external to the device. The memory may be used to

WO 2019/079845

PCT/AU2018/000210 store the operating system and additional software modules or instructions. The processors) may be configured to load and executed the software modules or instructions stored in the memory.

[00115] The present application describes a traffic monitoring system that can be used in arterial road traffic networks found in cities. Traffic monitoring apparatus 30 are located at intersections and other points in the network. These detect Bluetooth transmissions of Bluetooth devices in passing vehicles (or other vehicle identifiers) which is passed back to a traffic monitoring centre which uses a clustering approach to build up travel time profiles and variances for each link in the system as a function of day and time. This allows excess delay and a congestion parameter to be estimated for each link which can then be used to identify incidents and to generate a range of traffic status messages which can be broadcast by the Traffic monitoring Bluetooth transceiver apparatus. The system analyses the travel paths of vehicles approaching an incident and determines the incoming routes to the incident and generates alert message for Traffic monitoring Bluetooth transceiver apparatus (beacons) along the route which broadcast the alerts.

[00116] These traffic status messages include incident messages (eg estimated delays and causes if known), information messages, and travel time messages. The traffic monitoring apparatus 30 are configured to broadcast these traffic status messages using Bluetooth to traffic status listener apps on user devices along with a site ID. Traffic status messages can be embedded in a modified iBeacon format in which the major and minor fields are replaced with the dynamically generated traffic status message. This is an unconventional use of iBeacon messages which are typically static, and represents an efficient way to send a wide variety of messages with dynamic and content to the user apps. The app comprises a database that stores the locations of each site ID as well as message types and mappings of message codes to messages or values. On receiving a message the app can use the stored mapping to determine where the device is located (based on locations of site IDs) and generate a message which can be read out using a text to speech engine to alert the user of the app. By storing the site locations and message code mappings, compact messages can be used without requiring the user device to have an active data connection or GPS, thus saving device power. Further locations can be determined by receiving local beacon messages locality and site IDs, This also ensures the system is more robust in built up environments where GPS signals are weak or suffer from interference, and allows overlapping networks to be implemented. Further messages can be provided on roadside display (variable message signs) for any road (not just freeways). Another feature is that on detection of a new incident the system is configured to compare the new incident with known incidents and determine if the new incident should be merged. This allows suppression of excessive messages, and improved forward warning of incidents. Another feature is that the app can track the site IDs of Traffic monitoring Bluetooth transceiver apparatus that it passes to build up route histories which are stored on the user device. These route histories can be used along with phone sensors to generate pre-emptive messages. For example when the

WO 2019/079845

PCT/AU2018/000210 app detects movement of the user device (ie start of a journey) it can determine if there is a regular journey at this time, and obtain an estimate of the travel time that can be spoken to the user.

[00117] Those of skill in the art would understand that information and signals may be represented using any of a variety of technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[00118] Those of skill in the art would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software or instructions, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

[00119] The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. For a hardware implementation, processing may be implemented within one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, other electronic units designed to perform the functions described herein, or a combination thereof. Software modules, also known as computer programs, computer codes, or instructions, may contain a number a number of source code or object code links or instructions, and may reside in any computer readable medium such as a RAM memory, flash memory, ROM memory, EPROM memory, registers, hard disk, a removable disk, a CDROM, a DVD-ROM, a Blu-ray disc, or any other form of computer readable medium. In some aspects the computer-readable media may comprise non-transitory computer-readable media (e.g., tangible media). In addition, for other aspects computer-readable media may comprise transitory computer- readable media (e.g., a signal). Combinations of the above should also be included within the scope of computerreadable media. In another aspect, the computer readable medium may be integral to the processor. The processor and the computer readable medium may reside in an ASIC or related device. The software codes may be stored in a memory unit and the processor may be configured to execute them. The memory

WO 2019/079845

PCT/AU2018/000210 unit may be implemented within the processor or external to the processor, in which case it can be communicatively coupled to the processor via various means as is known in the art.

[00120] Further, it should be appreciated that modules and/or other appropriate means for performing the methods and techniques described herein can be downloaded and/or otherwise obtained by computing device. For example, such a device can be coupled to a server to facilitate the transfer of means for performing the methods described herein. Alternatively, various methods described herein can be provided via storage means (e.g., RAM, ROM, a physical storage medium such as a compact disc (CD) or floppy disk, etc.), such that a computing device can obtain the various methods upon coupling or providing the storage means to the device. Moreover, any other suitable technique for providing the methods and techniques described herein to a device can be utilized.

[00121] In one form the invention may comprise a computer program product for performing the method or operations presented herein. For example, such a computer program product may comprise a computer (or processor) readable medium having instructions stored (and/or encoded) thereon, the instructions being executable by one or more processors to perform the operations described herein. For certain aspects, the computer program product may include packaging material.

[00122] The methods disclosed herein comprise one or more steps or actions for achieving the described method. The method steps and/or actions may be interchanged with one another without departing from the scope of the claims. In other words, unless a specific order of steps or actions is specified, the order and/or use of specific steps and/or actions may be modified without departing from the scope of the claims.

[00123] As used herein, the term “determining” encompasses a wide variety of actions. For example, “determining” may include calculating, computing, processing, deriving, investigating, looking up (e.g., looking up in a table, a database or another data structure), ascertaining and the like. Also, “determining” may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory) and the like. Also, “determining” may include resolving, selecting, choosing, establishing and the like.

[00124] Throughout the specification and the claims that follow, unless the context requires otherwise, the words “comprise” and “include” and variations such as “comprising” and “including” will be understood to imply the inclusion of a stated integer or group of integers, but not the exclusion of any other integer or group of integers.

WO 2019/079845

PCT/AU2018/000210 [00125] The reference to any prior art in this specification is not, and should not be taken as, an acknowledgement of any form of suggestion that such prior art forms part of the common general knowledge.

[00126] It will be appreciated by those skilled in the art that the disclosure is not restricted in its use to the particular application or applications described. Neither is the present disclosure restricted in its preferred embodiment with regard to the particular elements and/or features described or depicted herein. It will be appreciated that the disclosure is not limited to the embodiment or embodiments disclosed, but is capable of numerous rearrangements, modifications and substitutions without departing from the scope as set forth and defined by the following claims.

[00127] Please note that the following claims are provisional claims only, and are provided as examples of possible claims and are not intended to limit the scope of what may be claimed in any future patent applications based on the present application. Integers may be added to or omitted from the example claims at a later date so as to further define or re-define the scope.

Claims (47)

1. A method for monitoring traffic in a road traffic network, comprising:

detecting, by a sensor in one of plurality of traffic monitoring apparatus, a vehicle identifier (ID) associated with a vehicle passing by or near to the traffic monitoring apparatus Bluetooth transmission of a nearby Bluetooth enabled devices, wherein the plurality of traffic monitoring apparatus are each located at a fixed site location in a traffic network;

sending, by a traffic monitoring apparatus, a capture message to a traffic network monitoring centre, the capture message comprising a site ID for the traffic monitoring apparatus; a representation of the vehicle ID, and a timestamp;

processing, by the traffic network monitoring centre, a plurality of capture messages to determine a link travel time for a link defined by two traffic monitoring apparatus, and obtaining an estimate of an excess delay and a congestion for each link, and one or more incident sites;

generating a plurality of traffic status messages, wherein each traffic status message has a traffic status message type and is generated according to a message format associated with the traffic status message type, and comprising the traffic status message type and a representation of at least one of the estimated link travel times, excess delay, congestion, and/or the incident site in the one or more message status fields;

transmitting each traffic status message to one or more of the traffic monitoring apparatus;

broadcasting, by each traffic monitoring apparatus that receives a traffic status message from the traffic network monitoring centre, a beacon message comprising the traffic status message using a Bluetooth transmitter; and listening, by a plurality of traffic status listener apps each executed on a user device, for a beacon message, wherein each traffic status listener app comprises a message database comprising a plurality of site records each comprising a site ID and the associated site location for each traffic monitoring apparatus in the traffic network, and a plurality of traffic status message types and associated message formats, wherein each message format comprises a traffic status message type field and one or more message status fields, and on receiving a beacon message, processing the beacon message by extracting the traffic status message type and parsing the traffic status message using the message format associated with the extracted traffic status message type to obtain the value in each message status field, and providing a representation of one or more of the values obtained from the processed beacon message to a user via the user device.

2. The method as claimed in claim 1, wherein the sensor is a Bluetooth receiver, and detecting a vehicle identifier (ID) associated with a vehicle passing by or near to the traffic monitoring apparatus comprises detecting one or more Bluetooth transmissions from a nearby Bluetooth enabled device, and

WO 2019/079845

PCT/AU2018/000210 extracting a Bluetooth address from each received Bluetooth transmission, and using the Bluetooth address as the vehicle ID.

3. The method as claimed in claim 1 or 2, wherein the road traffic network comprises a locality universally unique identifier (UUID) and the beacon message is transmitted in an iBeacon message format comprising a 16 byte UUID field, a 2 byte Major field and a 2 byte Minor field, and the locality is transmitted or encoded in the UUID field, and each traffic status message is a 32 bit message in which the first 16 bits are transmitted in the 2 byte Major field and the last 16 bits are transmitted in the 2 byte Minor field, wherein the site ID is included in the traffic status message, and on receiving a beacon message, processing the beacon message comprises extracting the locality from the UUID field, and the site ID from traffic status message.

4. The method as claimed in any one of claims 1 to 3, further comprising:

monitoring, by an incident manager service, the estimated excess delay and congestion for each link, and if the estimated excess delay exceeds an excess delay threshold for the link, and/or the congestion exceeds a congestion threshold for the link then the incident manager service created a new incident;

determining an incident site and a transmission set comprising the site IDs of one or more traffic monitoring apparatus at sites approaching the incident site using the received capture messages, sending, to each of the traffic monitoring apparatus in the transmission set, a traffic status message, wherein the one or more message fields comprises the estimated excess delay, congestion and/or incident site.

5. The method as claimed in claim 4, wherein determining a transmission set comprises: determining, using received capture messages from the incident site, the set of vehicle IDs detected at the incident site within a predetermined time period prior to the current time, identifying the site IDs of each previously passed site during a search time period prior to the current time for each vehicle ID in the set of vehicle IDs to obtain a total count of the number of vehicles passing each previously passed site during the search time period;

applying a volume filter to identify a set of candidate sites from the previously passed sites, generating an n-ary tree of sites IDs with the incident site at the head of the tree by determining the shortest path to the incident link from each of the candidate sites to create a branch of the n-ary tree; and applying a maximum length filter to each branch to prune the length to generate a set of transmission sites.

6.

The method as claimed in claim 4 or 5, further comprising:

WO 2019/079845

PCT/AU2018/000210 determining, by the incident manager service, if the new incident is upstream of an existing incident, and merging the upstream new incident into the existing incident if either all of the links from the new incident to the incident site of the existing incident have excess delays greater than zero and the new incident site is on a trunk from the existing incident site, or if the new incident site is on a secondary branch and is within three levels of the existing incident site, then the merging is performed such that the new incident adopts the incident properties of the existing incident and the n-ary tree of the incident is added to the n-ary tree of the existing incident.

7. The method as claimed in any one of claims 4 to 6, wherein one of the traffic status message types is an incident delay message type, and the associated message format comprises a traffic status message field containing an incident delay type code, a site ID field, an incident site ID field, an incident type code field, and a delay code field, and the message database stores the incident delay message type and the associated message format; and the traffic status message sent to each of the traffic monitoring apparatus in the transmission set is an incident traffic status message and the delay code field value is determined from the estimated delay for the site ID of the traffic monitoring apparatus that the traffic status message is sent to, and the method further comprises:

receiving by a traffic status listener app, an incident traffic status message;

extracting the incident delay type code from the traffic status message field and parsing the message using the associated format; and mapping the incident type code to the associated incident type messages and the delay code to a delay time; and providing a representation of incident site ID, the incident type message and the delay time to the user via the user device.

8. The method as claimed in claim 7, wherein one of the traffic status message types is a multiple incident delay message type, and the associated message format comprises a traffic status message field containing a multiple incident delay type code, a site ID field, an incident site ID field, and a delay code field, and the message database stores the incident delay message type and the associated message format;

and the method further comprises:

determining if a site ID of a traffic monitoring apparatus is included in two or more incidents, and if a site ID of a traffic monitoring apparatus is included in two or more incidents then an incident delay message is generated for each incident and stored by the message centre, and a multiple incident delay message type is generated and sent to the traffic monitoring apparatus wherein the incident site ID and the delay code included in the multiple incident delay message type is the delay for the incident with the largest delay;

WO 2019/079845

PCT/AU2018/000210 receiving a multiple incident delay message type by a traffic status listener app, extracting the multiple incident delay type code from the traffic status message field and parsing the message using the associated format; and mapping the delay code to a delay time;

initiating a data connection to the traffic network monitoring centre to obtain the plurality of incident delay messages for the site ID, and parsing each of the successfully received incident delay messages using the associated format and mapping the incident type code to the associated incident type messages and the delay code to a delay time; and providing a representation of each message to the user via the user device, wherein each representation comprises a representation of the incident site ID, the incident type message and the delay time for respective message.

9. The method as claimed in any one of claims 1 to 8 wherein one of the traffic status message types is an information message type and the associated message format comprises a traffic status message field containing an information message type field, a site ID field, a direction code field, and an information message code field, and the message database further comprises a plurality of direction codes and associated travel directions, and a plurality of information message codes and associated message strings, and the step of transmitting each traffic status message to one or more of the traffic monitoring apparatus comprises transmitting one or more information message to one or more of the traffic monitoring apparatus, and parsing the traffic status message using the message format associated with the extracted traffic status message type to obtain the value in each message status field comprises extracting the direction code value and mapping to the associated travel direction, and extracting the information message code and mapping to the associated message string, and the traffic status listener apps determines the direction of travel of the user device and provides a representation of the associated message string to a user via the user device if the determined direction of travel matches the extracted travel direction.

10. The method as claimed in claim 9, where one of the direction codes is a location marker code, and when a traffic status listener app extracts the location marker code, the traffic status listener app initiates a data connection to the traffic network monitoring centre to check if a custom message is available, and if the custom message is available, the traffic status listener providing a representation of custom message to a user via the user device.

11. The method as claimed in claim 9, where one of the direction codes is a download code, and when a traffic status listener app extracts the download code, the traffic status listener app initiates a data connection to the traffic network monitoring centre to download a traffic status message, and the traffic

WO 2019/079845

PCT/AU2018/000210

43 status listener app parses the downloaded traffic status message providing a representation of one or more of the values obtained from parsing the downloaded traffic status message to a user via the user device.

12. The method as claimed in claim 9, where one of the direction codes is a silence code, and when a traffic status listener app extracts the silence code, the traffic status listener app flags the site ID and prevents the generation of an audio representation of one or more of the values obtained from a processed beacon message to a user via the user device for beacon messages transmitted by the flagged site ID.

13. The method as claimed 7 or 8 further comprising:

detecting, by a traffic status listener app that the user device is moving, and logging the time the traffic status listener app receives a traffic status message from each traffic monitoring apparatus the user device passes to determine a trip path;

storing a trip log comprising the start time and origin site ID and end time and destination site ID of a trip, and a trip path;

identifying similar trip logs comprising similar trip paths and similar travel times;

determining a quality criteria for the trip logs;

wherein when the traffic status listener app receives an incident delay message, the traffic status listener app determine if the vehicle is travelling towards the incident location and that the quality criteria exceeds a threshold, then the trip logs are used to determine if the traffic status listener app has previously passed the site the incident delay message was received from within a search time period around the received time of the incident delay message, and if the trip logs do not include the incident site location in the trip path then the representation of one or more of the values obtained from the processed beacon message is suppressed.

14. The method as claimed 7 or 8 further comprising:

detecting, by a traffic status listener app that the user device is moving, and logging the time the traffic status listener app receives a traffic status message from each traffic monitoring apparatus the user device passes to determine a trip path;

storing a trip log comprising the start time and origin site ID and end time and destination site ID of a trip, and a trip path;

identifying similar trip logs comprising similar trip paths and similar travel times and grouping to obtain a group of similar trips over a common trip path;

wherein upon the traffic status listener app determining that the user device is moving, the traffic status listener app determines the originating time and originating site ID, and to search the trip logs to determine if a group of trips have started at the originating site ID within a search time period of the originating time, and if a matching group of trips is determined the traffic status listener app is configured to establish a data connection with the traffic monitoring centre and download one or more trip statistics for each link in the common trip path of the matching group of trips to determine an estimate of the total

WO 2019/079845

PCT/AU2018/000210 excess delay for the trip, and if the total excess delay exceeds a user defined threshold then a representation of the total excess delay is provided to the user via the user device.

15. The method as claimed in any one of claims 1 to 14, wherein one of the traffic status message types is a travel time message type and the associated message format comprises a traffic status message field containing a travel time message type field, a site ID field, a direction code field, and one or more destination travel time fields and the message database further comprises a plurality of destination mapping records each comprising a site ID and one or more of destination messages strings which each map to the one or more destination travel time fields in the travel time message fonnat, and a plurality of direction codes and associated travel directions, and the traffic network monitoring centre is further configured to generate, for one or more origin site IDs, one or more travel time messages wherein each of the one or more travel time messages is generated for one or more direction codes and each of the one or more destination travel time fields comprises an estimate of the travel time from the origin site ID to a destination site ID, the step of transmitting each traffic status message to one or more of the traffic monitoring apparatus comprises transmitting one or more travel time message to one or more of the traffic monitoring apparatus, and parsing the traffic status message using the message format associated with the extracted traffic status message type to obtain the value in each message status field comprises extracting the direction code value and mapping to the associated travel direction, and extracting one or more destination travel time values, and extracting the site ID and extracting the one or more destination messages strings in the destination mapping record for the site ID;

the traffic status listener apps determines the direction of travel of the user device and provides a representation of the destination travel time values and the associated destination message string to a user via the user device if the determined direction of travel matches the extracted travel direction.

16. The method as claimed in claim 15, wherein one of more of the traffic monitoring apparatus comprises a variable message sign with an associated direction code, and the traffic monitoring apparatus parses a received travel time message to extract the direction of travel and one or more destination travel times, and the variable message sign provides a visual representation of each of the extracted destination travel times if the extracted direction of travel matches the direction code the variable message sign.

17. The method as claimed in any one of claims 1 to 16 wherein one of the traffic status message types is a special beacon message travel time message type and the associated message format comprises a traffic status message field containing a special beacon message type field, a special beacon ID field, and a message field, and the message database further comprises the set of special beacon IDs and associated messages or app settings, the step of transmitting each traffic status message to one or more of the traffic monitoring apparatus comprises transmitting one or more special beacon messages to one or

WO 2019/079845

PCT/AU2018/000210 more of the traffic monitoring apparatus and parsing the traffic status message using the message format associated with the extracted traffic status message type to obtain the value in each message status field comprises extracting the special beacon ID, looking up the associated message or app setting in the message database, and either providing a representation of the associated message to the user via the user device or updating an app setting.

18. The method as claimed in any one of claims 1 to 17, wherein the representation is an audio representation generated by a text to speech engine, and the audio representation is sent to one or more audio output devices either integrated with the user device or connected to the user device over a wired or wireless connection.

19. The method as claimed in claim 18, wherein the user device is a mobile phone, and the mobile phone is connected to a vehicle audio system, and the one or more audio output devices are speakers in the vehicle connected to the vehicle audio system.

20. A traffic monitoring system comprising:

a traffic network monitoring centre comprising one or more processor and one or more memories operatively coupled to the one or more processors;

a plurality of traffic monitoring apparatus each comprising a Bluetooth transmitter, a sensor configured to detect a vehicle identifier (ID) associated with a vehicle passing by or near to the traffic monitoring apparatus, a communications module configured to establish a communication link with the traffic network monitoring centre, a memory configured to store at least a site ID and a processor operatively coupled to the memory, wherein each traffic monitoring apparatus is located at a fixed site location in a traffic network;

a plurality of traffic status listener apps which, in use, is configured to execute on a user device comprising at least one processor and a memory, wherein the memory comprises a message database, wherein the traffic network monitoring centre, the plurality of traffic monitoring apparatus, and the plurality of traffic status listener apps are configured to implement the method of any one of claims 1 to 19.

21. A traffic monitoring apparatus comprising a Bluetooth transmitter, a sensor configured to detect a vehicle identifier (ID) associated with a vehicle passing by or near to the traffic monitoring apparatus, a communications module configured to establish a communication link with the traffic network monitoring centre, a memory configured to store at least a locality UUID and a site ID and a processor operatively coupled to the memory and configured to send a capture message to the traffic network monitoring centre, the capture message comprising the site ID; a representation of the vehicle ID, and a timestamp, and the memory is further configured to store a site ID, wherein traffic monitoring apparatus is configured to receive a traffic status message from the traffic network monitoring centre and to

WO 2019/079845

PCT/AU2018/000210 broadcast a beacon message using the Bluetooth transmitter, the beacon message comprising the site identifier and the traffic status message in an iBeacon message format comprising a 16 byte UUID field, a 2 byte Major field and a 2 byte Minor field, wherein a locality is transmitted or encoded in the UUID field, and each traffic status message is a 32 bit message in which the first 16 bits are transmitted in the 2 byte Major field and the last 16 bits are transmitted in the 2 byte Minor field.

22. The traffic monitoring apparatus as claimed in claim 21, wherein the sensor is a Bluetooth receiver configured to detect one or more Bluetooth transmissions from nearby Bluetooth enabled devices, and the traffic monitoring apparatus is configured to extract a Bluetooth address and to use the Bluetooth address as the vehicle ID.

23. The traffic monitoring apparatus as claimed in claim 21 or 22, further configured to perform the steps of the method in of any one of claims 1 to 19 performed by one of the plurality of traffic monitoring apparatus.

24. A non-transitory computer program application configured to execute on a mobile computing apparatus, the non-transitory computer program application comprising a message database comprising a plurality of site records for a plurality of traffic monitoring apparatus in a traffic network, each site record comprising the site ID and the associated site location of a traffic monitoring apparatus, and a plurality of traffic status message types and associated message formats, wherein each message format comprises a traffic status message type field and one or more message status fields, and further configured to process a beacon message received by the mobile computing apparatus the non-transitory computer program application is executing on, wherein processing a beacon message comprises:

obtaining a traffic status message from the beacon message;

extracting the traffic status message type from the traffic status message and parsing the traffic status message using the message format associated with the extracted traffic status message type to obtain the value in each message status field; and providing a representation of one or more of the values obtained from the processed beacon message to a user via the mobile computing apparatus.

25. The non-transitory computer program application as claimed in claim 24, wherein the road traffic network comprises a locality universally unique identifier (UUID) and the beacon message is an iBeacon message comprising a 16 byte UUID field, a 2 byte Major field and a 2 byte Minor field, and the locality is obtained from the UUID field, and the traffic status message is a 32 bit message obtained by joining the Major field and the Minor field, and the site ID is obtained in a field in the traffic status message.

26. The non-transitory computer program application as claimed in claim 24 or 25, further configured to generate an audio representation by a text to speech engine, and to send the audio representation to one

WO 2019/079845

PCT/AU2018/000210 or more audio output devices either integrated with the mobile computing apparatus or connected to the mobile computing apparatus over a wired or wireless connection.

27. The non-transitory computer program application in claim 26, wherein mobile computing apparatus is a mobile phone, and the mobile phone is connected to a vehicle audio system, and the one or more audio output devices are speakers in the vehicle connected to the vehicle audio system.

28. The non-transitory computer program application in any one of claims 24 to 27, further configured to perform the steps of the method in of any one of claims 1 to 19 performed by one of the plurality of traffic status listener apps.

29. A traffic monitoring system comprising:

a traffic network monitoring centre comprising one or more processor and one or more memories operatively coupled to the one or more processors;

a plurality of traffic monitoring apparatus each comprising a Bluetooth transmitter, a sensor configured to detect a vehicle identifier (ID) associated with a vehicle passing by or near to the traffic monitoring apparatus, a communications module configured to establish a communication link with the traffic network monitoring centre, a memory configured to store at least a site ID and a processor operatively coupled to the memory and configured to send a capture message to the traffic network monitoring centre, the capture message comprising the site ID; a representation of the vehicle ID, and a timestamp in use, each traffic monitoring apparatus is located at a fixed site location in a traffic network;

a plurality of traffic status listener apps which, in use, is configured to execute on a user device and comprises a message database comprising a plurality of site records for each traffic monitoring apparatus in the traffic network, each comprising the locality, site ID and a plurality of traffic status message types and associated message formats, wherein each message format comprises a traffic status message type field and one or more message status fields, wherein the one or more processors and one or more memories in the traffic network monitoring centre are configured to receive and process the capture messages to determine link travel times for a link defined by two traffic monitoring apparatus, and to obtain an estimate of an excess delay and a congestion for each link, and to determine one or more incident sites, and generates a plurality of traffic status messages, each having a traffic status message type and is generated according to the message format associated with the traffic status message type, wherein at least one of the message status fields comprises a representation of at least one of the estimated link travel times, excess delay, congestion, and/or the incident site in the one or more message status fields, and each of the plurality of traffic status message are sent to one or more of the traffic monitoring apparatus in the network;

WO 2019/079845

PCT/AU2018/000210 each traffic monitoring apparatus that receives a traffic status message from the traffic network monitoring centre broadcasts a beacon message using the Bluetooth transmitter, the beacon message comprising the locality, site identifier and the traffic status message; and each traffic status listener app is configured to listen for and process a beacon message received by the user device the traffic status listener app is executing on, wherein processing a beacon message comprises extracting the locality and site location using the site ID, extracting the traffic status message type and parsing the traffic status message using the message format associated with the extracted traffic status message type to obtain the value in each message status field and providing a representation of one or more of the values obtained from the processed beacon message to a user via the user device.

30. The system as claimed in claim 29, wherein the sensor is a Bluetooth receiver configured to detect one or more Bluetooth transmissions from nearby Bluetooth enabled devices, and the traffic monitoring apparatus is configured to extract a Bluetooth address and to use the Bluetooth address as the vehicle ID.

31. The system as claimed in claim 29 or 30, wherein the beacon message is transmitted in an iBeacon message format comprising a 16 byte UUID field, a 2 byte Major field and a 2 byte Minor field, and the locality is transmitted or encoded in the UUID field, and each traffic status message is a 32 bit message in which the first 16 bits are transmitted in the 2 byte Major field and the last 16 bits are transmitted in the 2 byte Minor field.

32. The system as claimed in any one of claims 29 to 31, wherein traffic network monitoring centre further comprises an incident manager service executing on the one or more processors, wherein the incident manager service is configured to monitor the estimated excess delay and congestion for each link, and if the estimated excess delay exceeds an excess delay threshold for the link, and/or the congestion exceeds a congestion threshold for the link then the incident manager creates a new incident and determines an incident site and a transmission set comprising the site IDs of one or more traffic monitoring apparatus at sites approaching the incident site using the received capture messages, and the traffic network monitoring centre is configured to send a traffic status message to each of the traffic monitoring apparatus in the transmission set.

33. The system as claimed in claim 32, wherein the transmission set is obtained by using a plurality of the received capture messages to determine the set of vehicle IDs detected at the incident site within a predetermined time period prior to the current time, and for each vehicle ID in the set of vehicle IDs, identifying the site IDs of each previously passed site during a search time period prior to the current time to obtain a total count of the number of vehicles passing each previously passed site during the search time period, and applying a volume filter to identify a set of candidate sites from the previously passed sites, and generating an n-ary tree of sites IDs with the incident site at the head of the tree by determining

WO 2019/079845

PCT/AU2018/000210 the shortest path to the incident link from each of the candidate sites to create a branch of the n-ary tree, and applying a maximum length filter to each branch to prune the length to generate a set of transmission sites.

34. The system as claimed in claim 32 or 33, wherein when a new incident is created, the incident manager determines if the created incident is upstream of an existing incident, and merges the new incident into the existing incident if either all of the links from the new incident to the incident site of the existing incident have excess delays greater than zero and the new incident site is on a trunk from the existing incident site, or if the new incident site is on a secondary branch and is within three levels of the existing incident site, and the merging is performed such that the new incident adopts the incident properties of the existing incident and the n-ary tree of the incident is added to the n-ary tree of the existing incident.

35. The system as claimed in any one of claims 32 to 34, wherein one of the plurality of traffic status message types is an incident delay message having an incident delay message type and the associated message format comprises an a traffic status message field containing an incident delay type code, a site ID field, an incident site ID field, and incident type code field and a delay code field, and message database further stores a plurality of incident type codes and associated incident type messages, and a plurality of delay codes and associated delay times, at least one of the traffic status messages sent to a traffic monitoring apparatus in the transmission set is an incident delay message comprising a delay code field value determined from the estimated delay for the site, and each traffic status listener app that receives an incident delay message extracts and maps an incident type code to the associated incident type messages and the delay code to a delay time.

36. The system as claimed in claim 35, wherein one of the plurality of traffic status message types further comprises a multiple incident delay message type and the associated message format comprises multiple incident delay message type field, a site ID field, an incident site ID field, and a delay code field, wherein if a site ID of a traffic monitoring apparatus is included in two or more incidents, an incident delay message is generated for each incident and stored by the message centre and a multiple incident delay message type is generated and sent to the traffic monitoring apparatus wherein the incident site ID and the delay code included in the multiple incident delay message type is the delay for the incident with the largest delay , and on receiving a multiple incident delay message type by a traffic status listener app, the traffic status listener app provides a representation of the processed multiple incident delay message type to a user via the user device, and initiates a data connection to the traffic network monitoring centre to obtain the plurality of incident delay messages, and processes each of the successfully received incident delay messages, and provides a representation of each message to the user via the user device.

WO 2019/079845

PCT/AU2018/000210

37. The system as claimed in any one of claims 29 to 36, wherein the plurality of traffic status message types further comprises an information message type and the associated message format comprises an information message type field, a site ID field, a direction code field, and an information message code field, and the message database further comprises a plurality of direction codes and associated travel directions, and a plurality of information message codes and associated message strings, and one or more of the traffic status messages sent to a traffic monitoring apparatus is an information message type, and a traffic status listener app that receives the information message determines the direction of travel using the direction code, and the message string using the message ID, and provides a representation of the received information message to a user via the user device if the direction of travel matches the direction of travel of the user device.

38. The system as claimed in claim 37, wherein one of the direction codes is a location marker code, and when a traffic status listener app extracts the location marker code, the traffic status listener app is configured to initiate a data connection to the traffic network monitoring centre to check if a custom message is available, and if the custom message is available, the traffic status listener downloads the custom message and provides a representation of the custom message to a user via the user device.

39. The system as claimed in claim 37, wherein one of the direction codes is a download code, and when a traffic status listener app extracts the download code, the traffic status listener app initiates a data connection to the traffic network monitoring centre to download a traffic status message, and the traffic status listener app parses the downloaded traffic status message providing a representation of one or more of the values obtained from parsing the downloaded traffic status message to a user via the user device.

40. The system as claimed in claim 37, where one of the direction codes is a silence code, and when a traffic status listener app extracts the silence code, the traffic status listener app flags the site ID and prevents the generation of an audio representation of one or more of the values obtained from a processed beacon message to a user via the user device for beacon messages transmitted by the flagged site ID.

41. The system as claimed in any claim 36 or 37, wherein a traffic status listener app is configured to log the time it detects passing each traffic monitoring apparatus, and to detect the start and end of a trip and generate historical trip logs comprising a trip path and travel times for the same trip, and when a traffic status listener app receives an incident delay message, the traffic status listener app is configured to determine if the vehicle is travelling towards the incident location and if the quality of the historical trip data meets a quality criteria, then the historical trip logs are used to determine if the traffic status listener app has visited the current site around the same time and if the historical trip logs do not include the incident site location then the representation of one or more of the values obtained from the processed beacon message is suppressed.

WO 2019/079845

PCT/AU2018/000210

42. The system as claimed in claim 36 or 37, wherein a traffic status listener app is configured to log the time it detects passing each traffic monitoring apparatus, and to detect the start and end of a trip and generate historical trip logs comprising a trip path and travel times for the same trip, and the traffic status listener app is configured to detect when the traffic status listener app is in a moving vehicle, and upon detection, the traffic status listener app determines and is configured determine the originating time and location, and to search the historical trip logs to detennine if a particular trip is likely to take place based on the originating location and time, and if a matching trip is determined the traffic status listener app is configured to establish a data connection with the traffic monitoring centre and download one or more trip statistics for each link in the matching trip to determine an estimate of the total excess delay for the trip, and if the total excess delay exceeds a user defined threshold then a representation of the total excess delay is provided to the user via the user device.

43. The system as claimed in any one of claims 29 to 42, wherein the plurality of traffic status message types further comprises a travel time message and the associated message format comprises an travel time message type field, a site ID field, a direction code field, and one or more destination travel time fields and the message database further comprises a plurality of destinations associated with each site ID, a plurality of direction codes and associated travel directions, and the traffic network monitoring centre is further configured to generate a set of travel time messages for each direction code for one or more traffic monitoring apparatus, and a traffic status listener app that receives a travel time message determines the direction of travel using the direction code, and the travel times to each of the predetermined destinations using the travel time codes, and provides a representation of the received travel times to a user via the user device for each of the predetermined destinations if the direction of travel matches the direction of travel of the user device.

44. The system as claimed in claim 43, wherein a travel time message is sent to a variable message sign associated with a one or more traffic monitoring apparatus and a direction of travel, and the variable message sign provides a visual representation of the travel times to road users for each of the predetermined destinations for the direction of travel of the display.

45. The system as claimed in any one of claims 29 to 44, further comprising a plurality of special apparatus each comprising a Bluetooth transmitter and configured to store a special beacon identifier (ID) and transmit a special beacon message comprising a special beacon message identifier and the special beacon ID, and the message database further comprises the set of special beacon IDs and associated messages or app settings, wherein if a special beacon message is received, the app uses the special beacon ID to represent an associated message or update an associated app setting.

46. The system as claimed in one of claims 29 to 45, wherein the representation is an audio representation generated by a text to speech engine, and the audio representation is sent to one or more

WO 2019/079845 PCT/AU2018/000210 audio output devices either integrated with the user device or connected to the user device over a wired or wireless connection.

47. The system as claimed in claim 46, wherein the user device is a mobile phone, and the mobile phone is connected to a vehicle audio system, and the one or more audio output devices are speakers in the vehicle connected to the vehicle audio system.