Abstract
1. Introduction
The rapid increase in road traffic appears to be one of the major problems facing urban and sub-urban areas in recent years. Traffic congestion and jams are one of the main reasons for immensely increasing transportation costs due to the wasted time and extra fuel. Traffic reports in real-time are essential for alleviating congestion in overcrowded cities, as well as allowing commuters the choice of proper routes to avoid becoming stuck in traffic for hours. Several initiatives have been proposed and implemented to gather traffic data to feed the ITS [1]. According to our survey, most efforts focus on limited installation of fixed sensors such as loop-coils and intelligent video cameras with image processing capability. However, the costs of such implementations are very high due to the high cost of the devices, installation and maintenance. Moreover, these fixed sensors are vulnerable to extreme weather in certain areas. An alternative way to collect traffic data at a lower cost with wider coverage is therefore needed [1].
Even if drivers attempt to avoid daily rush hour traffic, the circumnavigation of all suddenly arising traffic congestion is mostly impossible with current traffic management systems. To manage this challenge in the future, the U.S. Federal Highway Administration (FHWA) identified three general approaches to reduce traffic congestion [2]:
Extension of the current base capacity, e.g., increase of the number and size of highways.
Encouragement of alternative travel and land use concepts that require fewer resources, e.g., non-automotive travel modes.
Using the existing capacities more efficiently.
The approach proposed in this paper focuses on the third strategy. As stated in the FHWA final report [2], all of these three strategies reduce traffic congestion, but strategies for a more efficient use of existing capacities have the most effective impact, since they concentrate on the basic cause of the problems instead of only alleviating the negative effects.
RFID technology is one of the most rapidly growing segments of today's automatic identification data collection (AIDC) industry [3]. “RFID tags” on objects or assets, and “RFID readers” are used to gather the tag information. RFID represents an improvement on bar codes in terms of non-optical communication [4]. The VTCE system based on RFID is designed for all legally registered vehicles which must hold RFID tags. When these vehicles travel along a road or intersection in which a VTCE system is installed [5] [6], the vehicle tag information is read and sent immediately to the CCS unit for the purposes of real-time monitoring and management of vehicle movement conditions.
This paper is organized as follows: section 2 introduces the principles of RFID. Section 3 describes the VTCE system. Section 4 discusses the software of VTCE. Section 5 describes the simulation of roads and traffic intersections. Section 6 discusses the traffic congestion estimation strategy. Section 7 gives the application of VTCE, and finally, the conclusion is given in section 8.
2. Principles of RFID Technology
RFID is not a new technology, for example, the principles of RFID were employed by the British in World War II to identify their aircraft using the IFF system (Identity: Friend or Foe) [7]. Today RFID is a generic term for technologies that use radio waves to automatically identify people or objects [4]. A typical RFID system will comprise RFID tags, RFID reader and middleware, see Fig. 1.

Components of an RFID system
Each RFID tag has a unique serial code or ID, and placed in or attached to the object to be identified. It contains information on the basic properties of the object [8]. An RFID tag responds to a reader query with its fixed unique ID. This fixed ID enables tracking of tags and the bearers. Some tags carry information about the objects they are attached to [9]. A reader detects the tags that is attached to or embedded in the selected items. It varies in size, weight and may be stationary or mobile. The reader communicates with the tag through the reader antenna, which broadcasts radio waves and receives the tag's response signals within its reading area. After the signals from the tag are detected, the reader decodes them and passes the information to middleware [6].
Typically, an RFID middleware platform performs aggregation of data across different readers and forwarding of relevant data to subscriber servers or application-level systems, and persistent storage for received data [10]. However, an RFID middleware is often given the task of managing, monitoring and configuring the different readers [11].
In VTCE, an Alien ALR-9800 Enterprise RFID Reader type is chosen, because it fulfils most of the RFID hardware's property requirements, such as it operates with UHF frequency, multi-static antenna, multiple antenna ports and support Ethernet connection.
3. VTCE System Architecture
The VTCE project is divided into two parts, software and hardware. The software part is programmed using the Microsoft Visual Basic 2010 program and the large database system is designed by Microsoft SQL Server 2008 R2 Management Studio. The hardware part consists of RFID readers, which are simulated by the use of the Rifidi Platform [12] and Roads and Traffic Intersections Simulator (RTIS). Rifidi is a program designed to simulate an RFID system and to perform as a hardware reader. It is the premier open source simulator for RFID. Also, we designed an RTIS program to simulate the physical movements of vehicles, the RFID tags on vehicles and the road network with traffic intersections.
The system architecture of the VTCE is shown in Fig. 2. It can be seen that this system mainly consists of RFID tags attached to all vehicles, two RFID readers and four antennas on each reader. In each branch two RFID antennas are installed, they can simultaneously scan in opposite directions from the two vehicles and can record relevant information for each vehicle.

Architecture of VTCE based on RFID
The two RFID antennas are located in the median island of the road near the traffic intersection and separated by a convenient distance. This architecture of arranging the direction of antennas means the antennas' RF radiation areas do not overlap with each other. In the CCS, according to the order of receiving the same tag ID from two different antennas, the direction of vehicle movement will be known from its entry to its exit. In this system architecture, the VTCE will monitor the path direction for all vehicles in the traffic intersections in real-time.
The CCS performs management, monitoring and maintenance on the communication with the readers, and contains the middleware and database server [10]. Figure 3 shows how the CCS is connected with the RFID readers and the database.

The layout of the VTCE environment
4. VTCE Software
The VTCE software is run directly on the CCS, the middleware requests the database to obtain the requirements to establish connections. These requirements include the traffic intersection's ID, the RFID reader's IP and Port and the RFID reader's Username and Password. After the response is received from the database the system starts the connection with the readers and begins requesting the readers to get the gathered tag list over periods of one second.
The data received in the form of a package from the reader must be processed through several steps and filters, as shown in Fig. 4. The package information is filtered as tag ID, antenna number, date and time. This information will be stored in an online data table. If the antenna number is even, the package data are stored in a temporary table and if the antenna number is odd, the system requests to search in the temporary table for that tag ID. When both even and odd packages are obtained together, the system will infer the vehicle ID that has passed through, traffic intersection ID, from-road, to- road, date, in-time and out-time. The inferred information will be stored in the vehicle location table. The next step is to check whether this vehicle ID is in a black list table or not. If this is detected then the system displays a warning message that includes the ID of the vehicle passing through the traffic intersection, from-road, to- road, date and the time.

Flowchart of middleware performance
5. Roads and Traffic Intersections Simulator (RTIS)
5.1 The RTIS Architecture
Before introducing the VTCE project into a real-life situation, the ability, functionality, efficiency and further effects have to be tested carefully. To evaluate the improvements that can be achieved, simulations have to be conducted. Hence, a realistic simulation of road and traffic intersection scenarios is needed. Various parameters are needed to simulate the traffic, the VTCE communication with readers, the application and the environment [2].
Traffic includes the physical movements of vehicles on an arbitrary road network. WiMAX wireless Ethernet communication between CCS and readers [13] is simulated via Wi-Fi wireless Ethernet communication. Application simulation means the simulation of applications that are to be integrated in real-world vehicles. For this purpose, inner vehicle interfaces have to be emulated to allow the application to interact with RFID readers, such as attached RFID tags on vehicles. The last part is the environment simulation which includes the road network with traffic intersections. Also, a TCP/IP server is built to simulate the connection method in RTIS such as the Alien ALR-9800 Enterprise RFID reader. The VTCE connection with RTIS is like the connection with the real Alien readers.
5.2 The RTIS Scenario
To evaluate the effectiveness of the VTCE and to identify potential problems, a simple simulation scenario has to be considered. For this reason, a special region is selected which has seven in-out ways and five traffic intersections. One intersection is composed of three roads intersected and the others are composed of four roads intersected. This region is chosen because it provides a good road structure for VTCE tests.
An intersection ID is given to each intersection such as (146, 147, …,150). Ten RFID readers are to be simulated; two readers to each intersection as shown in Fig. 5. Several vehicles are simulated and each vehicle is given a specific vehicle ID and tag ID. The speed of vehicles moving can be controlled in RTIS. These vehicles move on the road network along a random path. Several routes are designed for each vehicle on road network. The vehicle selects a specific route to pass through by implementing a random function.

The vehicle and road network in RTIS
The RTIS simulates the RFID reader to scan and receive tag IDs from vehicles. The virtual reader accumulates these data until it receives the ‘Get TagList’ instruction from the VTCE. Then, it will send the gathered data to VTCE in CCS by the TCP/IP server. The RTIS is designed for creating a scenario that is almost real. All the unnecessary or unpredictable factors that can influence the results, such as side road traffic or complex traffic light systems, are avoided in order to provide significant results.
6. Proposed Traffic Congestion Estimation Strategy (TCES)
Reporting road traffic congestion can be a confusing task since there is no adopted standard for measuring congestion [14]. Typical users need a concise and easy to understand traffic report. The normal traffic situation can be roughly categorized into two states, open and congested [15], but such a classification is not enough to describe the traffic situation. Thus, in the VTCE project three traffic patterns have been adopted to facilitate quick and easy steps to understand the report [14], namely, Red (Traffic Jam), Yellow (Slow Moving), and Green (Free Flow) are defined as the following:
Traffic Jam: there are a very large number of vehicles and almost all of them run very slowly and this will be represented by red colour.
Slow Moving: there are a large number of vehicles and most of the vehicles run at half speed and this will be represented by yellow colour.
Free Flow: there are a minimum number of vehicles and the vehicles run at normal speed in the region of interest and this will be represented by green colour.
To determine a congestion level, the following three steps are carried out:
6.1 Computing the Average Time Spent
To compute the average time that is required to pass the street, in the first step the system gets the time from GUI. Then, the system goes back five minutes. Therewith, it requests the IDs of the vehicles that have left the street within those last five minutes. In the next step, the system recalls the entry time into the street for those vehicles. Then, it subtracts the exit time from entry time for each vehicle as depicted in Fig. 6. The last step is computing the time average using the sum of the spent time of all the vehicles and divides it by the number of vehicles.

The flowchart for traffic congestion status estimation
6.2 Computing the Average Speed of Vehicles
The system will compute the average speed of vehicles after it gets the distance of the street from the traffic intersections table. The system computes the average speed of vehicles by dividing the distance on average time spent.
6.3 Determining the Congestion Level
After the system obtains the average speed of vehicles in the street, in the next step, congestion levels are classified using speed into three levels: red, yellow and green. The VTCE project uses two classification thresholds, γ and δ, for adjusting parameters of the algorithm, as follows [14]:
Green level, if the average speed is larger than or equal toy.
Yellow level, if the average speed less than γ and larger than δ.
Red level, if the average speed is less than δ.
At the end, the user obtains from the system the average required time taken to pass the street and the average speed of vehicles in the last five minutes, as well as estimating the traffic congestion level.
7. VTCE Applications
7.1 The Traffic Congestion Appraisal
The VTCE system supports some applications for the data that are gathered and analysed. The traffic congestion appraisal is one of them. This application can estimate the congestion in two conditions; along the street or within the intersection.
Figure 7 shows the GUI of intersection congestion appraisal. Appraisal of traffic intersection congestion is used to estimate the required time to cross the intersection. It calculates the average of the required time to cross the distance between the antenna of entry and the antenna of exit. This application uses only the first step of the TCES. The traffic intersection ID should be entered in its specific field. The congestion can be appraised for the time being (default) or at the previous date and time by selecting its button then specifying the date and time. The suggested system uses α and β criteria to estimate the status of congestion in the intersection. The system enables α and β to be changed by the user via clicking on the

The traffic intersections congestion appraisal
Figure 8 shows the GUI of street traffic congestion appraisal. The street congestion appraisal is a very important application of VTCE. Using this application the street congestion status can be estimated in real-time. The user must specify the street and the direction of traffic. This is done by giving the ID of the intersection, i.e., from-intersection to-intersection. The time must be specified at the present time (default) or on the previous date and time by selecting its button. In this application the system uses γ and δ criteria to decide the status of traffic congestion in the street. γ and δ are the range of vehicles' speed criteria (in km/Hr) that pass along the street. VTCE system enables the user to change γ and Δ.

The street traffic congestion appraisal
This application uses all steps in the TCES. By clicking on the
7.2 Traffic Congestion Status Website
The VTCE system collects useful data from intersections about vehicle movements. These data are only allowed for administrator use. Two websites are designed to allow any user to benefit from traffic congestion estimation applications as shown in Fig. 3. Via these websites, the user can avoid traffic congestion by checking the congestion status by intersection or street.
The intersection congestion status estimation website estimates the required time to cross the intersection. This application uses only the first step of the TCES. The client (user) should enter the traffic intersection ID. The website loads the present date and time, and α and β criteria, automatically. The website enables the user to change α and β criteria and specify previous date and time. By pressing on the

The website of intersection congestion estimation
The street congestion status website is designed for any user (driver) to check the congestion status of a street before joining it. The user ought to define the street by from-intersection ID to-intersection ID. The website loads the present date and time, and γ and δ criteria, automatically, or they can be defined manually. This website uses all steps in the TCES. By clicking on the

The website for street congestion estimation
7.3 Street Traffic Congestion Appraisal / SMS Server
In the VTCE project, the Street Traffic Congestion Appraisal / SMS Server (STCA/SMS) is designed so that a user can obtain information about street congestion without access to the Internet. This is done by sending an SMS message to the STCA/SMS server. The STCA/SMS server is composed of two parts: STCA and GSM modem, (see Fig. 2). The STCA receives the request from the GSM modem and calculates the congestion status at the present time by the use of TCES, see Fig. 11. Then, it sends the reply to the GSM modem.

Street Traffic Congestion Appraisal / SMS Server
A GSM modem is a wireless modem that connects a computer to a GSM network. Like a GSM mobile phone, a GSM modem requires a SIM card in order to operate. Figure 12 shows the established communication between the cellular network and the computer via GSM Modem [16].

GSM modem communications
An external GSM modem is connected to a computer by a serial cable. It is possible to make and receive phone calls and send text messages. AT commands must be used for establishing communication between the GSM modem and the computer [16]. AT commands are the set of commands that are specified for controlling a GSM phone or modem and managing the SMS feature of GSM. In the VTCE project, the Sony Ericsson Mobile Phone Modem AAD-3880020-BV has been used along with the Sony Ericsson built-in modem software. The VTCE modem is programmed by AT commands with Protocol Description Unit (PDU) format mode [17]. It is used to send/receive SMS messages to/from the user (the driver). The GSM modem receives the SMS message from GSM network and sends it to STCA and vice versa, as depicted in Fig. 13.

Sony Ericsson GSM modem configurations
The user must send a message in a specific format. The message ought to start with the (STCA) symbol, capital or small, followed by a space. Then, the user must specify the street by entering the ID of the intersection followed by a space and the ID of the next intersection, for example (STCA 150 149). The message is sent to the service number; the modem receives a message and sends it to STCA/SMS server. The server will send the reply to the modem to send it to the user.
8. Conclusion
Vehicle Traffic Congestion Estimation based on RFID is a project with a goal to gather information about the vehicles passing in any specific traffic intersection. This information is then utilized to determine the traffic status of a road network. This goal is realized by installing RFID readers in all these intersections and attaching RFID tags to all vehicles, whereupon these readers send the information to a CCS. The proposed VTCE project uses the TCES to classify the report into three traffic patterns, namely, Red (Traffic Jam), Yellow (Slow Moving) and Green (Free Flow), which may also be extended to classify five patterns, if needed. The proposed VTCE project uses this information in three different applications; The Traffic Congestion Appraisal for the administrator, Traffic Congestion Status Website for Internet users and Street Traffic Congestion Appraisal / SMS Server for GSM mobile users. It is important to note that if the proposed VTCE system is to be implemented, then large data need to be provided by the traffic authorities for testing to ensure the robustness of the system.
