Security through Traffic Network: Tracking of Missing

Security through Traffic Network: Tracking of Missing Vehicles and Routing in TMIS using Semantic Web Services Atilla Elçi Dept. of Comp. Eng. and Internet Technologies Research Center Eastern Mediterranean University, Famagusta, TRNC, Turkey atilla.elci @emu.edu.tr

Behnam Rahnama Dept. of Comp. Eng. and Internet Technologies Research Center Eastern Mediterranean University, Famagusta, TRNC, Turkey behnam.rahnama @emu.edu.tr

Abstract This study highlights a security scenario involving vehicles in a Traffic Management and Information System (TMIS) network. TMIS and its nodal architecture Intelligent Junction (IJ) are summarized from recent work. Their design employs autonomous semantic agent-based software, sensor networks, and wire/wireless integrated communication infrastructure. Especially described are their essential functions crucial to aid security applications. A security scenario concerning tracing and tracking of missing vehicles is considered and shown how to implement it over TMIS network. Simulation results show promising outcomes. Research involving similar development base is suggested. Keywords: TMIS, traffic network, intelligent junction, semantic Web services (SWS), service ontology, vehicle tracking, RFID, multi-agent systems.

1. Introduction Traffic Management and Information System (TMIS) manages a traffic network and avails information. It is a distributed autonomous application designed using semantic Web technology and multiagent systems approach. It is implemented through interconnecting “intelligent junctions” in the topology of an urban traffic network. TMIS, due to its intelligent junction base, proves decisive in tracking of missing vehicles. This paper initially summarizes salient design features of TMIS/IJ and then a security scenario concerning tracing and tracking of missing vehicles is considered. TMIS design has recently been considered at length [Elci-2005]. TMIS design choices lead to new software architecture for distributed environments using autonomous semantic agents. While according

Amirhasan Amintabar Dept. of Comp. Eng. and Internet Technologies Research Center Eastern Mediterranean University, Famagusta, TRNC, Turkey amirhasan.amintabar @emu.edu.tr

extensive inter-connectivity, flexibility and concomitant reliability, simulation studies showed tolerable overhead levels. Simulations show high performance and benefit of load distribution using Intelligent Junctions. Design of IJ has been worked out in a recent study [Elci-2006]. Its design involves employing autonomous semantic agent based software, sensor networks, and wire/wireless integrated communication infrastructure. Simulation study of IJ carried out for the purposes of the present study hints at extensive usability for autonomous and cooperative functionality needed in TMIS sort of applications. Similar findings are expected in a developmental research project being conducted to study cooperation of multiple mobile robot-based autonomous semantic agents in cooperatively solving an unknown labyrinth.

2. TMIS: Traffic Information System

Management

and

TMIS uses IJs as its core. TMIS architecture and its components are illustrated in the following figure. Junctions provide the required information for Junction Management unit. The rest of the system is an information system for collecting and retrieving the required information through semantic web. For such a system client-server solution is possible, yet it would create a bottleneck at the central site. Centralized control and the resultant application mode tend to become “command & control driven”. On the contrary, SWS approach distributes load to network by delegating capability to processing nodes. Using a distributed infrastructure without strict central control accords us the possibility of enlarging the system at will and flexibility of network topology modification. For agents are operating in concurrent and cooperating manner, exploiting parallelism in problem solving is another aspect of this new architecture [Elci-2005].

GPRS/ EDGE/ WiMAX

Environment Variables Set

Junction Manager SWS Junction Manager SWS

Shared TMIS Ontology Environment Variables Set

TCP/IP Network UDDI

Server Client Monitoring

GPRS/EDGE / Wimax

Critical Path Finder

Database of: ƒ Policies ƒ User I/F ƒ Reporting

TMIS Server

Emergency Service API Critical Path Navigator

Ambulanc e Services Facilitator

Environment Variables Set

Figure 1. TMIS architecture and components.

Taking advantage of semantic Web technology to represent network topology, node configuration, business policy, and performing objective functions, accord an IJ with power to reconcile with its environment. IJs can cooperate in resolving their share of information request problems through taking advantage of neighbors’ semantic data. While collating an answer in response to a user query, IJs cooperate in broadcasting the query to the network.

2.1. Simulation of Message Passing in TMIS It was feared that the message broadcasting modus operandi might cause excessive load on the network thus invalidating any advantages gained. In order to determine exact behavior, and if possible, work out an upper bound on the number of messages, simulation experiments were carried out. Simulations of network models showed close to linear incremental load on the communication network. For example, for a typical network representative of real traffic junction system, message load increases linearly with the number of intersections. Simulation of network models of sizes one up to ten ASAs for traffic network was conducted using Message Passing Interface 2.0 [MPI-2.0] on VMware v.5 Parallel Virtual Machine [VMware]. MPI is a message-passing software library facilitating communication for exchanging data and synchronization of tasks among processors in a distributed-memory parallel processing environment.

Three different traffic network models were considered based on topology: linear, intermediate, and mesh. Linear network is akin to a train road where stations line up along tacks and essentially there are no intersections. The linear model is the simplest of the three; although unrealistic, it is included here as a boundary / best case. The mesh model is the most complicated traffic network consisting of fullyconnected junctions; that is, all intersections connect to all others, definitely quite unrealistic as traffic networks come. The mesh model is included here as the worst-case topology. On the other hand, the intermediate model is selected to be quite realistic. Table 1. Maximum number of messages due to message propagation in all models for up to 10 ASAs. Number of Nodes

Number of Messages

1

Linear Model 0

Intermediate Model 0

Fully Connected Mesh Model 0

2

1

1

1

3

2

3

3

4

3

5

6

5

4

7

10

6

5

9

15

7

6

11

21

8

7

13

28

9

8

15

36

10

9

17

45

Table 1 depicts the maximum number of total messages passed in the network due to propagation of a single message from one node. Obviously these are worst-case scenarios. The numbers are given for all three models. The same is charted in Figure 2. 50 45 Number of Messages

Junctio

45

Fully Connected Mesh

40 36

35 30

28

25 21Intermediate Model 17 15 13 11 9 8 7 6

20 15

15 10 7 4

10 5 0

1

0 1

2

6 5 3

3 2 3

4

5

9 5 6

Linear Model

7

8

9

10

Number of Nodes

Figure 2. Number of passed messages versus network size

The growth trend is clearly linear for linear and intermediate models. In the case of the mesh model, it grows similar to Fibonacci series, as maximum number of messages for size n is the sum of n-1 and that of size n-1 where base cases are 1 and 0. In reality results would be better, because a node having received a message would not send it to the links it received it from; also if the node can respond to a message there is no reason for forwarding it further. These shortcuts will likely reduce message propagation traffic drastically.

3. IJ: Intelligent Junction Intelligent Junction (IJ) is an essential component of the TMIS model introduced above. IJ administers its junction lights, senses vehicles from the moment they approach till they leave the intersection, recognizes and interacts with them meanwhile noting all contextual implications. IJ implements the conventional intersection lights management by sequencing and timing them. IJ takes guidance from the policy delegated to it; yet it performs autonomously also heeding local traffic situation and other prevailing exigencies. In doing so, IJ consults its ontology and contextual knowledge base. It cooperates with and complies with requests coming from the neighboring IJs and from the TMIS application running in the central facility. These issues are further taken up below. IJ may be likened to a processing node if TMIS is taken for a grid. IJ is a composition of Junction Manager Software, its associated policy, ontology and database, server platform, various peripherals consisting of sensors, displays, traffic lights, networking and communication equipment. The Junction Manager Software (JMS) performs as server of several junction administration and information functions: handling traffic lights, driving the information display panels, Controlling / interacting with the sensory network, communicating with the wide area network, and interacting with vehicle / driver client. JMS provides much of this functionality through a semantic Web services interface. There will be displays conveniently located based on information service needs around the junction. These are for informing the public and the drivers, guidance, prompting and advisory messages about the traffic situation in the junction and beyond. Displays are handled by JMS as per its policy and service ontology. Displays network work probably by wired medium. As with the lights, TMIS can have the information services modified such as turning of the displays facing a closed road. Figure 3 depicts a divided road junction, Intelligent Junction Manager and peripherals. Intelligent Junction (IJ) is a hub of semantic Web services (SWS) structured to manage a traffic

intersection generically; it is a semantic agent which performs autonomously (ASA). IJ interacts with other IJs managing the neighboring junctions and with the central server application overseeing / monitoring the TMIS. IJ is normally in contact with inhabitants of the junction (vehicles, drivers, passengers, and pedestrians) through elaborated sensor, communication, input and display networks lay out in the junction. For example, as a vehicle enters a junction (i.e., an IJ’s sphere of influence), it gets noticed through its vehicle tag being sensed. Subsequently, IJ can further recognize a vehicle through fetching information about it if any exists in its junction database; alternatively, it may inquire neighboring IJs, leader junction and the central server application for the same. Such ubiquitous sensing can readily be put to application in security needs [UBISEC].

Junc. Mgr SWS

GPRS / EDGE / WiMAX

Lights & Displays

Figure 3. Intelligent Junction at a divided road intersection

4. Tracking and Reporting a Vehicle in TMIS/IJ Vehicle tag is a remotely-sensable identification device (possibly a RFID tag) inconspicuously attached to a vehicle such as part of its chassis number plate or embedded inside dashboard. It allows identification of a vehicle uniquely through its particulars such as make, model, year, chassis number, etc. Alternatively, the tag can simply supply a unique key which is used to fetch the corresponding information from databases. IJ maintains its local databases among which two are of prime interest in this vehicle tracking security application: the Report-At-Sight (RAS) and Vehicle Sighting Exception (VSE) lists. RAS contains details of vehicles reported as missing and not-yet-located or cleared. VSE contains the reports of missing vehicles detected by this IJ.

Upon detecting a vehicle in the junction, IJ compares vehicle info against its RAS. If a match is found, a VSE is then issued carrying additional data on locale, date, time, heading (direction, link). The VSE is sent to only the neighboring junctions who then forward it to their neighbors. Eventually, VSE propagates to the junction that is executing the Vehicle Tracking and Reporting (VTR) application. VTR is a TMIS-wide specific service being offered by one of the junctions possibly the leader one. Note that the role of the leader junction is more of a monitoring or overseeing nature rather than being a command-andcontrol center. VTR is capable of interacting with the reporting IJ and that of the IJ towards where the suspect vehicle is heading; and possibly may request them to route the suspect vehicle; all that are accomplished through SWSs. VTR can propagate the sighting exception to other designated services / applications such as Traffic Department Legal Cases and Security Department Patrol Dispatch for action at their end. Tracking and reporting a vehicle in TMIS/IJ have been studied through simulation introduced in the next section. It should be noted that the following have been granted as axioms: ƒ A junction can contact its neighbors only; ƒ A missing vehicle alert may be raised (input by external actors) at any junction as well as at the leader junction or received by VTR from external sources; ƒ A missing vehicle may appear at any junction any time (Poisson distribution); ƒ To stop screening junction traffic looking for a specific missing vehicle only the leader junction can issue an advisory and propagate it over to all junctions.

Accordingly, an IJ upon sensing (reading) a missing vehicle in its jurisdiction area will report the fact as a VSE to its neighboring junctions. Consequently, the leader junction will also receive this report. A leader junction, upon receipt of a VSE will take two actions: ƒ Report this result to the police department; ƒ Initiate a missing vehicle detected message (MVD) and announce it to other junctions to end the duty and stop the search process. To do this, the leader junction propagates the MVD message to the neighboring junctions. As a result, a junction upon receipt of an MVD message, regarding the detection of the missing vehicle, understands that its duty to watch for that missing vehicle is over. The simulation model was organized as a set of segments, each of which representing activity of one junction. The number of segments representing junctions can be varied to simulate the whole traffic network with different number of junctions. All these segments are linked to one another to model a complete traffic system. The topology of the traffic network is a directed graph which is represented by an adjacency matrix where each entry is a directed link between two junctions. For example, in the adjacency matrix, the entry at (i, j) = 1 indicates that vehicles can travel from junction i to j, i.e., a one way link exists from junction i to junction j (Figure 4).

5. Simulation Model of TMIS/IJ A junction upon receipt of a Missing Vehicle Alert (MVA report indicating a missing vehicle), will take the following actions: ƒ Store the missing vehicle’s information into its local database; ƒ Start watching for the missing vehicle in its jurisdiction area; ƒ And, spread this message to its neighbors. The missing vehicle’s information could be its plate number or its RFID tag value. One of the junctions also acts as the leader junction to monitor others’ actions. The leader junction is directly in contact with the metropolitan police department. So, sending any message to this junction, eventually leads to receipt of that message by the metropolitan police department and vice versa. Its duty, upon receipt of an MVA is listed as follows: ƒ To record this information into the RAS List in its DB; ƒ Also, to report the alert to VTR application.

Figure 4, A TMIS network (A) and its corresponding adjacency matrix (B)

In the simulation approach, as well as modeling the traffic network, behavior of a missing vehicle is also investigated. A missing vehicle, in this system behaves in the following manner; on the entrance to a junction it decides on which junction to be the next destination. Hence, to simulate the behavior of the missing vehicle a set of probabilities is assigned to outgoing edges of each junction. These probabilities are stored in an exit probability matrix. In fact a missing vehicle leaving junction i, is assumed to choose its destination based on the probabilities listed in the row i of the exit probability matrix. Therefore, sum of probabilities in each row is 1. Figure 5.A corresponds to exit probability values of Figure 4.A. In fact, the values of probabilities can be derived from a long-running observation over a real traffic system on the region and stored in a look-up table. Then the exit probabilities

can be retrieved from that look-up table for various time periods and situations of the traffic system. In the exit probability matrix, junction number zero indicates the area over which no junction has control, that is, the traffic area out side of TMIS jurisdiction. So, if a missing vehicle leaves from any junction to junction zero, it means that the missing vehicle is not in reach any longer. Another matrix maintains the average traveling time for each link. It is called time matrix throughout this work. A typical example of a time matrix associated with Figure 4.A is shown in Figure 5.B. Again, these values can be derived from a long term observation of traffic in a real system. In Figure 5.B, the parameter k, stands for unknown values. For example, we don’t know how long it takes for a missing vehicle leaving junction 3 to reach junction 0 which in fact is an unknown destination. It is because when we don’t know the destination, we can not predict the travel time. In the time matrix NA stands for Not Applicable, where there is no link.

Figure 5, A) The exit probability matrix. B) The time matrix (in min) related to Figure 4.

6. Performance of TMIS/IJ To investigate the performance of TMIS in security applications such as tracking and tracing a missing vehicle, the response time of the system is of concern. In other words, we are interested to see whether the system is able to detect the missing vehicle within a reasonable period of time. For this reason, response time is defined as the duration from which an MVA report reaches a junction to the time the corresponding VSE reached that junction from any junction that has detected the missing vehicle. This period is in fact the summation of the time needed for propagation of the messages in TMIS, plus the time starting from the alert reported till the time the missing vehicle appeared at one of the junctions. This can be defined in the expression (1) as follows: RT = d(MVA) + TT + d(VSE).

(1)

where, RT is the response time, d(MVA) is the propagation delay of the MVA message, d(VSE) is propagation delay of the VSE message back to the initiator junction. TT is the travel time which is the period from the alert initiated to the time the missing vehicle detected.

It is clear that the propagation delays are negligible when compared to the time the missing vehicle travels to reach one of the junctions. Hence, we can make this approximation on (1) in (2). RT ≈ TT

(2)

When a vehicle is discovered missing, an actor usually reports this fact to the nearest junction which is termed as ‘the initiator junction’. From then on, by the time the missing vehicle reaches the next junction, the alert message MVA has already reached all the junctions. So, we can assume that if the missing vehicle is still inside the TMIS area, it will be trapped once exposed to the next junction. Hence, considering (2), the expression below is valid: m

RTmean(i) ≈ ave (TT(i,j)) =

∑ AD j =0

(i , j )

× TT(i , j ) × P(i , j ) .

i ∈ {1..n}, m=n

(3)

where, RTmean(i) is the average response time for when the missing vehicle was departing the junction i at the time of alert. The ‘ave (TT(i,j))’ is the average travel time which takes the missing vehicle reaching one of the neighboring junctions. TT(i,j) is the travel time read from the time matrix, and P(i,j) is taken from the exit probability matrix and AD(i,j) is taken from the adjacency matrix. For example, considering the network given in Figure 4, if we assume that when the alert was given the missing vehicle has just left junction 1, then the mean response time is estimated as follows: RTmean(1) ≈ 0 × NA × 0 + 0 × 0 × 0 + 1 × 7 × 0.4 + 1 × 11 × 0.6 + 0 × NA × 0 = 9.4, (4) which happened to be independent of the parameter k. This phenomenon happens (i) while the missing vehicle roams well inside the TMIS, not on the boarder junctions, and (ii) the missing vehicle is roaming at a border junction but the junction has no exit link to junction 0, that is, outside of TMIS. The assumption of roaming only inside TMIS is the same as setting to zero all the links leading to junction 0 in the adjacency matrix. Hence, in the expression (3) if we vary j starting from 1: RTmean(i) (for ∀ j = 0 AD(i, j) = 0) ≈ m

∑ AD j =1

(i, j )

× TT ( i , j ) × P( i , j ) .

i ∈ {1..n}, m=n

(5)

where, none of i or j gets the zero value. Consequently k parameter will not appear in the expression (5).

In general we don’t know in between which two junctions the missing vehicle was located when the alert reported. So, the average travel time between any two junctions in TMIS will give us a good approximation on the average response time: RTmean =

1 n ∑ RTmean(i ) n i =1

(6)

Applying the expression (6) on any TMIS system returns RTmean in a linear combination of a number and the parameter k, which based on the results from the expression (5), it can be summarized below:

RTmean

1 n m = ∑∑ AD(i , j ) × TT(i , j ) × P( i , j ) = n i =1 j = 0

1 n 1 n m ( AD(i,0) × ki,0 × P(i,0) ) + ∑∑AD(i, j) ×TT(i, j) × P(i, j) ∑ n i=1 n i=1 j=1 ⇒ RTmean = f(ki,0) + cte i ∈ {1..n}

(7)

where cte means a number value. Indeed, when the missing vehicle is outside the TMIS we can’t make any comment about it except that the average response time will be more than a certain amount which is cte in (7). In the simulation approach the propagation delay of delivery of a message from a junction to its neighbors is assumed to be distributed exponentially. In the simulation experiment done on the network depicted in Figure 4, this value is assumed to be 5 ms which is in agreement with the actual delivery time of frames in LANs [Korkmaz] [Amintabar]. The simulation was carried out in the simulation system MATLAB 6.5 [Mathlab] in the Windows operating system. MATLAB is a simulation tool which is based on matrices to perform all the calculations in the simulation process. Since, from a simulation point of view, TMIS can be considered as a non-terminating system, its steadystate performance measures are of interest. To decrease the effect of the transient state, each simulation run was long enough to ensure that about 5000 MVA happened in the system. To compare the simulation results with the analytical modeling, taking TMIS of Figure 4 as an example, Table 2 given below summarizes the simulation results and analytical approximations using expression (3). It shows a close match between the two approaches where the missing vehicle is assumed to be inside the TMIS area, here junctions 1 and 3 which have no direct connection to junction 0, the outside world. However, for the other junctions which have exits to the outside of TMIS, the simulation results come up with uncertainty wherever the missing vehicle can leave TMIS. For example, for junction 2 the result of simulation for when the missing vehicle has not left

the TMIS, matches the analytical approximations. However, if the missing vehicle leaves junction 2 to junction 0 and in fact leaves the TMIS area, the result of simulation becomes unpredictable. Table 2. Response time of TMIS in Figure 4 initiating from different junctions Node # Response time (min)

Analytical

Simulation

Node # Response time (min)

Analytical

Simulation

1 9.4

2 4.8 when the MV is inside the TMIS 4.8 + 0.6K2,0 otherwise. (K2,0 is unpredictable) 9.4003 4.807 when the MV is inside the TMIS, Unpredictable otherwise. 3 4 8.7 4 when the MV is inside the TMIS 4 + 0.6K4,0 otherwise. (K4,0 is unpredictable) 8.71 4.0023 when the MV is inside the TMIS Unpredictable otherwise.

In general, when the missing vehicle is very close to the borders it is likely that it changes its path towards the outside world to escape from being captured. However, in the middle of TMIS the missing vehicle usually is surrounded by the junctions that sooner or later will observe it and report it through a VSE message.

7. Conclusions, Prospects & Future Work Features of TMIS/IJ design have been utilized in other distributed applications with or without command & control requirement. IJ’s implementation of SWS-based, cooperating agent, and cognitivesemantic support have also been carried over to a mobile robot. This may be called as Autonomous Semantic Agent- Mobile (ASAM). Together with TMIS’s multi-agent nature, such robots can then be used to solve problems cooperatively. Such designs then coined as Multi-ASAM (MASAM) architecture. The case in point is the CLD Project we’ve evolved on finding an exit of an uncharted labyrinth by multiple robots working cooperatively. The design novelties of the robot are highlighted in [Rahnama]. Research on the reliability of TMIS/IJ design is being initiated. Essentially, except the case of TMIS with segmented sub-networks where only a single link failure may cause partitioning, continuity of service is assured. This is so because of re-configurability through MAS nature of the design where each agent can subsume any other agent’s duties, and availability of multiple paths between any two points in a TMIS. Nevertheless, the effects of link failure and the security of service through re-configurability of TMIS/IJ design may need to be researched [PEPERS] [DESEREC]. Certain limitations of the simulation study reported above have been noted. Simulation is based on a synchronous model. This provided fairly acceptable

approximation as indicated by the concurrence of analytical and simulation based response time calculations. On the other hand, as many unrelated events happen in far-flung niches of TMIS, real life case could be better mimicked by an asynchronous approach. Simulation is based on an M/M/1 model, so a single customer gets served at any time at a junction; in a way, links are served one-at-a-time and each is single lane! Whereas distribution of traffic in a real-life system is dynamic hence the rates get updated continually, while this study assumed fixed probabilities of traffic loads (duty fixed exit probabilities) in links. Extensions along these factors may be investigated in the future. In the future, various other applications similar in nature to VTR may as well be considered concerning vehicles. Similar cases are also feasible involving drivers, passengers, and pedestrians should they be carrying a wearable identification device.

8. Acknowledgement This work was supported by the Fund for Enhancement of Academic Research in Higher Education by Ministry of Education and Culture, TRNC, as Project MEKB-05-01 Cooperative Labyrinth Discovery (Robotics Competition).

9. References [Amintabar] Amintabar A., Kostin Alex., Ilushechkina L., Simulation of a Novel Leader Election Protocol with the Use of Petri Nets, Proc. 9th IEEE International Symposium on

Distributed Simulation and Real-Time Applications, Montreal, Canada (DS-RT) 2005 Oct, pp. 283-289. [DESEREC] -, Dependable security by enhanced reconfigurability, http://www.deserec.org. Last accessed on 25 Aug. 2006. [Elci-2005] Elçi, Atilla and Rahnama, Behnam: Considerations on a new Software Architecture for Distributed Environments using Autonomous Semantic Agents, Proc. 29th COMPSAC, IWSC 2005, 26-28 July 2005, Edinburgh, UK,;IEEE Press, ISBN: 0-7695-2413-3, ISSN: 0730-3157, pp.: 133-138. [Elci-2006] Elçi, Atilla and Rahnama, Behnam: “Intelligent Junction: Enhancing Quality of Life through Traffic Management”, Proc. YvKB’06 4th Congress on Informatics in Built and Municipality, Ankara, 8-9 June 2006, p.: 67-74, TBD Publications, ISBN: 9944-5291-0-9 (in Turkish). [Korkmaz] Korkmaz, G.; Ekici, E.; Ozguner, F., A CrossLayer Multihop Data Delivery Protocol With Fairness Guarantees for Vehicular Networks, Vehicular Technology, IEEE Transactions on, Volume 55, Issue 3, May 2006 Page(s):865 – 875. [Mathlab] http://www.mathworks.com. Last accessed on 25 Aug. 2006. [MPI-2.0] http://www-unix.mcs.anl.gov/mpi/. Last accessed on 29 Aug. 2006. [PEPERS] -, Mobile peer-to-peer security infrastructure, http://www.pepers.org. Last accessed on 25 Aug. 2006. [Rahnama] Rahnama, Behnam and Elci, Atilla, Upon human-robot inter communication, RO-MAN 06 Robot Companion Design Contest, Proc. the 15th IEEE International Symposium on Robot and Human Interactive Communication, 6-8 September 2006, University of Hertfordshire, Hatfield, UK. [UBISEC] -, Ubiquitous sensing and security in the European homeland, http://www.ist-ubisecsens.org. Last accessed on 25 Aug. 2006. [VMware] http://www.vmware.com/. Last accessed on 29 Aug. 2006.