Computers & Electronics

Remote Mobile Nodes Service Delivery via VANET

Description
Human beings, naturally, love to do super things or to be super heroes at doing some things and show people their abilities, and because some of them are irresponsible people, driving at high speed might be an example of a combination result of
Published
of 6
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
   1 Remote Mobile Nodes Service Delivery via VANET Maythem Kamal Abbas 1 , Azween B. Abdullah 2    Department of Computer and Information sciences Universiti Teknologi PETRONAS  Bandar Seri Iskandar, 31750 Tronoh, Perak, Malaysia.  Maythem: eng_maythem_84@yahoo.com, Azween: azweenabdullah@petronas.com.my Abstract    Human beings, naturally, love to do super things or to be super heroes at doing some things and show  people their abilities, and because some of them are irresponsible people, driving at high speed might be an example of a combination result of acting as super drivers and having fun irresponsibly.  In this paper, we illustrate the speed control part of our suggested system & its application layer  protocol to solve the above problem “High Speed  Driving” as well as describing our proposed specification logic language for VANET Aspects.  By applying this system on highways, we will save lives of the victims and/or the irresponsible people or at least reduce the total amount of car accidents happening every day.[7] Though, this system’s expected cost is high, saving one life is more worthy.  Keywords:  Vehicular Ad-hoc Network (VANET)  ,  Ad-hoc Networks  ,  Networks On Wheel (NOW)  ,  Vehicle-To-Vehicle Communication (V2V)  ,  & Vehicle-To- Infrastructure Communication (V2I), DSRC. 1. Introduction We can get the benefit of Vehicular Ad-Hoc  Networks (VANET) to save people lives by making some VANET devices working together comprising a networking system between cars & road side equipments fixed on highways to control people’s cars remotely and limit their speed. These devices are Coordinator Device (Co_D), Road Side Equipments (RSE), & End Device (ED)/ Vehicle VANET Device (VVD). There is a forth participating device named Police vehicle VANET Device (PVD) that will be explained in our future papers that has no roles to do in cars speed control. PVD combines some of Co_D’s features and some others of the RSE’s to do its job. VVD and PVD models look like that they both have the same functions to do, but actually they are not. 2. Contributions Our research has two main contributions; the first is a formal specification logic language for VANET that can be used for describing VANET aspects mathematically, while the second contribution is a layered system that can be used by VANET entities to deliver orders and services to the mobile participants. A lot of researches were done on VANET field but none used or contributed specification logic for VANET environment and none of them (till September-2008) suggested using the fixed infrastructure of VANET to apply a physical force to control car speeds. 3. Related Work    Vehicular Ad-Hoc Network (VANET) is a form of Mobile Ad-Hoc Network (wireless Network), srcinally was used to provide safety & comfort for  passengers, & currently being used to establish dedicated short range communications (DSRC) among near by Vehicles (V2V Communications) and between vehicles and nearby fixed infrastructure equipments; Roadside equipments (V2I Communications). [14,2,10,8,15] VANET was used also to warn drivers of collision  possibilities, road sign alarms, auto-payment at road tolls and parks.[12,5] Usually VANET used & still being used with ITS (intelligent transportation Systems).[13,9] A project was lately done (September 2007) its title was: “Application Level Protocol for Accident reconstruction in VANETs”.[1]   A research project was done on 2004, its title was: “Engineering and simulation of mobile ad-hoc routing  protocols for VANET on highways and in cities”, which is aiming the routing protocols development for the Mobile Ad-Hoc networks.[11] Also there is a master’s project aiming to improve the broadcasting reliability in VANET Environment,   2 that was done in 2006, “  Increasing Broadcast  Reliability In Vehicular Ad-Hoc Networks ”.[3] There are many Information Dissemination researches within VANET environment have been done, some of them are very beneficial and successful, while others were not studied in carefully enough. An example of Information Dissemination projects is; “Optimizing Dissemination of Alarm Messages in Vehicular Ad-Hoc Networks (VANET)”; was done in 2004, [4], mainly they proposed to a scheme for alarm messages dissemination when accidents happen to warn other vehicles about the accident in a more efficient way by restricting rebroadcast to only special nodes, named “relays”. Two French motorway companies are involved with different players of the ITS business, in projects related to infrastructure/vehicle communications: SAFESPOT and CVIS. SAFESPOT started on Feb 2006 to develop a project which mainly aims to understand and assess, trough test in real condition, the  potential of the cooperative approach in term of road transport safety improvement, which addressed 12  problems can be solved by the project. This project costs about € 38 Million and will last in four years time. 51 partners from 12 different European countries supporting this project.[6] The CVIS (Cooperative Vehicle-Infrastructure Systems) started a project on Feb 2006, FP6 Integrated Project aims to develop and test new technologies to allow road vehicles to communicate with any nearby roadside infrastructure. Based on such real-time road and traffic information, many novel applications can  be produced. The consequence will be increased road safety and efficiency, and reduced environmental impact. 61 partners from 12 countries are cooperated to work and sponsor this project which costs about € 41 Million and planned to be done within 4 years time.[6] 4. Methodology VANET has many aspects to be described, so we found none of the previous researches have used or have contributed a specification language to describe those VANET aspects. We started studying those aspects and creating a language to describe them mathematically. VANET ideally works in an integrated environment (V2V & V2I) but the most of the researches focused on V2V communications while underestimating the V2I’s ability to control the roads, to deliver services into remote mobile nodes, and to locate mobile nodes without using the costly GPS. 5. Proposed Specification Logic In this section, we illustrate each notation of our  proposed Logic language; these would be useful for describing different VANET aspects. Table 1 – Proposed basic Symbols / Notations A B  A can reach B, while B can  NOT. A B  Both of A & B can reach each other. A Ξ  B  A controls B – A has the  jurisdiction over B A ►  B A moves to area B A ◄  B A moves away from B A ▲  B A speeds up within area B A ▼  B A slow down within area B A ⌂  B A stops within B A A U-turns  A θ  B A sees B A ~x> B  A sends a message type-x to B A <x~ B  A receives back a reply message type-x from B Mtx -1  Waiting for a reply message (Type-x Message) F 1   F 2  Function-1 Sparks / Calls Function-2 (a,b,c,…) > X  insert a record into table X (a,b,c,…) <   X  Get a record values from table X A Vs. B  Compare A with B   Not &  And |  Or A B  A trusts B A B  A Does NOT trusts B / A revokes the trust from B A & B & … C, D if (A & B) then C & D A & B & … !   C if Not (A & B & …) then C  6. Layered System Specific Abbreviations In this section, we are illustrating the abbreviations used in our proposed system: Table 2 – Abbreviations Mtc Is a function that checks the Message type (Mt) & decides the destiny of the incoming message. PAz Is the incoming packet analyzer function, it analyses the packet according to the  packet type. SF Is a set of “Set functions”. GF Is a set of “Get functions”. SQL Is the function that creates SQL statements, their type (Query or Setting type) depends on the Mtc function’s output. PFr Is a function that is responsible of forwarding   3  packets to ports. PCr Is a function used to create Packets, their type (Unicast / Broadcast,   speed code or searching packets ) depends also on the output of the Mtc function. 7. Proposed System In this section we illustrate our proposed system then specify formally the messages exchanged within the system using our proposed specification logics ( See Table 1 ). Our system has N number of layers but there are three main layers which can be sub-layered: 1-   Layer one: Co-ordination layer (L1) 2-   Layer two: Distribution Layer (L2) 3-   Layer three: Host Layer (L3) Each layer has its own features those are common to all devices belong to that layer, While each device has its own unique features and abilities. Figure 2 - Proposed Layered system Each layer has its own devices working in: 7.1. Layer 1 Devices ( α ):  Let    α  = { α A, α B, …, α n } Where: α A : L1 Device-A α B : L1 Device-B n: a number  Let    α A  = { α A F, α A T, α A P} Where: α A F: L1 Device-A Functions α A T: L1 Device-A Tables α A P: L1 Device-A Ports  And let  : α A F = { α Mtc , α Paz , α Sf  , α Gf  , α SQL , α Pcr  , α Pfr  , *** MORE FUNCTIONS*** } α A T = { α Spc [a][b], α SMT [c][d], α VT [e][f], α SCT [g][h], ToR  [i][j]} α A P = { α P1 , α P2 } Then: α A  = { α Mtc , α Paz , α Sf  , α Gf  , α SQL , α Pcr  , α Pfr  , α Spc [a][b], α SMT [c][d], α VT [e][f], α SCT [g][h], α ToR  [i][j], α P1 , α P2 } 7.2. Layer 2 Devices ( β ):  Let    β  = { β A, β B, …, β n } Where: β A : L1 Device-A β B : L1 Device-B n: a number  Let β A  = { β A F, β A T, β A V, β A P} Where: β A : L2 Device-A β A F: L2 Device-A Functions β A T: L2 Device-A Tables β A V: L2 Device-A Variables β A P: L2 Device-A Ports  And Let: β A F = { β Mtc , β Paz , β Sf  , β Gf  , β Pcr  , β Pfr  , *** MORE FUNCTIONS*** } β A T = { β VT [e][f], β SCT [g][h]} β A V = { β Spc , β Rsq } β A P = { β P1 , β P2 , β P3 } Then: β A  = { β Mtc , β Paz , β Sf  , β Gf  , β Pcr  , β Pfr  , β VT [e][f], β SCT [g][h], β Spc , β Rsq , β P1 , β P2 , β P3 } 7.3. Layer 3 Devices ( Γ ):  Let    Γ  = { Γ A, Γ B, …, Γ n } Where: Γ A : L1 Device-A Γ B : L1 Device-B n: a number 7.3.1. For device-A of layer3 ( Γ A ):  Let Γ A  = { Γ A F, Γ A T, Γ A P} Where: Γ A : L3 Device-A Γ A F: L3 Device-A Functions Γ A T: L3 Device-A Tables Γ A P: L3 Device-A Ports  And Let: Γ A F = { Γ Mtc , Γ Paz , Γ Sf  , Γ Gf  , Γ Pcr  , Γ Pfr  , *** MORE FUNCTIONS*** } Γ A T = { Γ RT [e][f], Γ ST [g][h]}   4 Γ A P = { Γ P1 , Γ P2 } Then: Γ A  = { Γ Mtc , Γ Paz , Γ Sf  , Γ Gf  , Γ Pcr  , Γ Pfr  , Γ RT [e][f], Γ ST [g][h], Γ P1 , Γ P2 } 7.3.2. For device-B of layer3:  Let Γ B  = { Γ B F, Γ B T, Γ B V, Γ B P} Where: Γ B : L3 Device-B Γ B F: L3 Device-B Functions Γ B T: L3 Device-B Tables Γ B V: L3 Device-B Variables Γ B P: L3 Device-B Ports  And Let: Γ B F = { Γ Mtc , Γ Paz , Γ Sf  , Γ Gf  , Γ Pcr  , Γ Pfr  , *** MORE FUNCTIONS*** } Γ B T = { Γ RT [e][f]} Γ B V = { Γ SCT_Flag } Γ B P = { Γ P1 } Then: Γ B  = { Γ Mtc , Γ Paz , Γ Sf  , Γ Gf  , Γ Pcr , Γ Pfr  , Γ RT [e][f], Γ SCT_Flag , Γ P1 } 7.4. Devices Communications In this section we describe the properties of the connections between the layers devices and the assumptions: -   All connections are assumed to be Bi-Directional & existent Connections. -   An existent Routing protocol already been configured by the system administrator. -   Connection between α  & β  devices assumed to be existed 24 hours a day for 7 days a week. -   Connections between α  & β  devices can be wire or wireless, while Connection between β  & Γ  devices should be wireless. -   β  devices can communicate each other. -   Connection between β  & Γ  devices can be Active or In-Active connections. -   α B  can have only one active connection, either with α A  or β A  devices. Layer-1 devices can communicate Layer-2’s & Layer-2 devices can communicate Layer-1 devices when required: α A      β A At the same time, Layer-1 devices have a full control on Layer-2 & Layer-3 devices: α A   Ξ   β A And: α A   Ξ   Γ x Layer-2 devices are connected to each other so they can reach each other: β Ax    β Ay  Layer-2 Devices can reach Layer-3 devices when required and Layer-3 devices can reach layer-2 devices: β A      Γ x So, Layer-1 Devices can reach Layer-3’s only through layer-2 devices. α A      β A    Γ x Layer-3 device-B, has limited abilities compares to Layer-1 Device-A, Γ B  can reach layer-2 devices only, while Γ A  can reach Layer-2 devices as well as Layer-3 devices. Γ B      β A  While: Γ A      β A  And: Γ A      Γ B  As well as, Layer-3 Device-A can control Layer-3 device-B: Γ A   Ξ   Γ B 8. A Case study As we have mentioned before, our proposed system has 3 main layers these have their own devices, for our casr study we are implementing a VANET environment into the system: Let Co_D is an α A  device Let RSE is a β A  device Let VVD is a Γ B   device (a car) Each device has different functions to implement & different messages to understand and behave according to their types. Each device will get input from another while gives output to a third one. The system was setup as shown in F igure-1 . Let’s briefly explain how this system works. By  placing a VANET Device inside a car to control another device (e.g. electrical/Mechanical valve) located near by the fuel pump on the fuel pipe (the hardware design of the speed control is optional for the car’s manufacturers), the VANET device would receive a propagated number from a roadside equipment. That number represents the Maximum Allowed Speed on that road (which is specified by National Highway Traffic Safety Administration – NHTSA of the implementer country), so the vehicle’s VANET Device will allow the car’s fuel pump to pass a   5 maximum amount of fuel enough only for that maximum allowed speed (Not more than that). 8.1. Cars Speed limitation on highways Description For the basic scenario, Figure 1 , the coordinate device (Co_D) sends out the required speed (e.g. 60 Km/h) to the nearest Road side equipment which in turn re-transmits the received speed code to the next nearest router, and so on. While each router propagates that speed code, VVDs of Cars within its coverage area would receive that code and digitize it to control an electric valve (placed near by the carburetor/Injectors of the car) gate, permitting only a certain amount of fuel to be  pumped / injected into the engine at the full pedal step. That amount is decided by the received speed code which represents the maximum allowed speed on that road. Figure 1 - Basic design/scenario 8.2. Messages Flow In this section we are illustrating in details how would the system behave when it’s used for the car speed limitation case study. 8.2.1. Issuing Speed code Message α A  ~Q> β Ax : (MtQ, Rsq( β Ax ), #Hp, #SpC) When Layer-2 Device-A receives a message, it checks its type to decide what how would it be analyzed: Let IMsg = (MtQ, Rsq( β Ax ), #Hp, #SpC) Where: IMsg: Incoming Message Let NMsg 1 = (MtQ, Rsq( β Ax ), #Hp-1, #SpC) Where: NMsg 1  = New Message-1 β Mtc  (IMsg)    β Paz (Rsq( β Ax ), #Hp, #SpC) , β Pcr  (NMsg 1 ) β Pcr       β Pfr   (NMsg 1 , β P3 ) when its Mtc function finds out that the incoming message’s type is MtQ, it would call Paz function to start analyzing the rest of the message as (Rsq, #Hp, #SpC), as well as, Mtc would call Pfr function to forward the message to the next Layer-2 device-A. 8.2.2. Broadcast Speed Code Message β A  ~R> Γ B : (MtR, Rsq( β Ax ), #SpC) After Layer-2 device analyzes the incoming message into its values, Paz would sparks Pcr function to create a new message typed-R (MtR) that would be  propagated to Layer-3 Devices ( Γ ) through port-2 ( β P2 )  by β Pfr function: Let NMsg 2  = β Pcr   (MtR, Rsq( β Ax ), #SpC) Where: NMsg 2  = New Message-2 β Pcr       β PFr  (NMsg 2 , β P2 ) 8.2.3. Issue/Send L1 Node status report Γ B ~S> β A : (MtS, CR) When a layer-3 Device-B receives a propagated message, it would first try to identify the message type  by using Γ Mtc Let IMsg = (MtR, Rsq( β Ax ), #SpC) Where: IMsg: Incoming Message  Now, Mtc function recognized the message type as MtR, it would call Paz function to analyze the rest of the incoming message as (Rsq( β Ax ), #SpC): Let NMsg 3  = (MtS, CR) Γ Mtc  (IMsg)    Γ Paz (Rsq( β Ax ), #SpC) , Γ Pcr  (NMsg 3 ) Γ A  would keep the information of the incoming message source device in RT table: (Rsq( β Ax ), RSE_IP) >   Γ RT [][] As we can see, Mtc sparked Pcr function to create a message type-S that contains the report (CR) that would be unicasted to the RSE that currently in touch with (this can be found in RT table). Γ Pcr    Γ Pfr  (NMsg 3 , Γ P1 ) 8.2.4. Unicast L1 Node status report β A  ~T> α A : (MtT, CR, Rsq) After receiving an incoming message by a Layer-2 Device-A & recognizing its type as MtS, its Mtc
Search
Similar documents
View more...
Tags
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks
SAVE OUR EARTH

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!

x