A MULTI-LAYER COOPERATION FRAMEWORK FOR QOS-AWARE INTERNET ACCESS IN VANETS
Antonio Iera, Antonella Molinaro, Sergio Polito, Giuseppe Ruggeri University Mediterranea of Reggio Calabria, Italy {name.surname}@unirc.it ABSTRACT A VANET is composed of vehicles, equipped with short range wireless communication capabilities, which cooperate to form a temporary distributed network enabling communications with other vehicles or road infrastructure nodes, located in line of sight or even out of the radio range (if a multihop network is built among vehicles). It is clear that granting to vehicles continuous and high-quality connections to the Internet is a very challenging objective, due to the dynamicity of vehicular networks. In this paper, we discuss some inter-layer cooperation principles that could drive the augmentation of widely deployed protocols, at the application and network layers, to provide vehicular users with the best available Internet access. Keywords: VANET, QoS, Internet connectivity, gateway, AODV, SIP. 1 INTRODUCTION delivery requirements, and ask for the network capability to offer continuous access to the Internet together with a controlled Quality of Service (QoS). The capability to satisfy these requirements will prove to be a great value-added service and will be a critical factor to the success of vehicular networks. In spite of these strong requirements, providing QoS-aware on-board Internet connectivity is a very challenging objective, due to the intermittent nature of wireless links in the high mobile and high dynamic vehicular environment. It is only recently that the research community has focused on the task of providing Internet connectivity to vehicles [4-8]. Their approach is to exploit the presence of gateway nodes in the VANET. Gateways can either be stationary (or roadside) units placed at fixed positions alongside roads, or mobile (or on-board) units traveling on some vehicles and acting as mobile gateway for other vehicles with just a short-range radio interface. Vehicle to gateway communications can exploit inexpensive IEEE 802.11 equipments; gateways to Internet (or to infrastructure) communications exploit longer range technologies, as cellular radio links or wired links. Given that vehicles do not necessarily know the position and availability of all gateways in their neighborhood, the effectiveness of procedures for discovery and selection of the "best" gateway, which users' traffic has to be delivered through, turns to be a factor of utmost importance. The gateway selection may depend on a multiplicity of factors, involving user and application requirements, network availability and features, agreements with service providers, location of the gateway, quality and stability of the (multihop) path to the candidate gateway in the VANET. Above
Vehicle-to-vehicle and vehicle-to-infrastructure communications have turned into an important research area over the last few years. The growing importance of this area has been recognized by governments, corporations, and the academic community [1]. As a result, spectrum has been allocated for inter-vehicular communications (in the 5GHz frequency band), and many research projects and partnerships in this area have been recently started. Vehicles on the roads dynamically form continuously changing topology networks, which are referred to as Vehicular Ad-hoc Networks (VANETs). Studies in [2] have demonstrated that communications among vehicles can exploit the short-range IEEE 802.11-based radio interface technology. Currently, the IEEE working group 802.11p is specifying a new physical layer and MAC (medium access control) enhancement for intervehicular communications in the 5GHz frequency band [3]. In terms of MAC operations, the new standard will be based on the Enhanced Distributed Channel Access (EDCA) of IEEE 802.11e. Numerous applications are emerging as unique to the vehicular environment. They include both safety and non-safety applications. Safety applications aim at providing drivers information about critical situations in order to prevent accidents and make driving safer. Non-safety applications (e.g., gaming, mobile commerce, multimedia streaming) aim at entertaining the users and improving driving comfort and efficiency of transportation system. These applications are typically bandwidth-demanding, have real time
UbiCC Journal – Volume 3
1
reported considerations clearly define the choice of the right gateway as a multi-layer issue that implies cooperation among protocol layers. In fact, service subscription and pricing usually pertain to the user/application level; setting up a QoS-demanding application is a typical session initiation problem; finding the route to a gateway is usually accomplished through network-layer procedures and, finally, collecting information about the state of a link is fulfilled by MAC/Physical layer functions. In this paper, we propose a QoS framework, which provides cooperation among augmented versions of some popular protocols: Session Description Protocol (SDP), with extensions to capability negotiation as proposed in [9] that can be used for SIP-initiated multimedia session description, Ad hoc On-Demand Distance Vector (AODV) [10] routing protocol used to set-up multihop path to the gateway in the VANET, and IEEE 802.11e [11] MAC/Physical interaction to rule channel access and choose the most reliable path to the gateway. This paper is organized as follows. Section 2 summarizes main achievements in current literature for Internet gateway discovery in vehicular networks. Section 3 gives details of our cooperative multi-layer framework to provide passengers in vehicles with QoS-aware on-board Internet access. Main simulation results are reported and discussed in Section 4, and conclusions are summarized in Section 5. 2 RELATED WORK
Methods for enabling nodes within a mobile ad hoc network (MANET) to obtain Internet connectivity through fixed or mobile gateways have been proposed in literature [10, 12, 13]. In most of these works, gateway discovery is considered as an extension of the routing protocol, this means that the routing protocol is augmented with gateway discovery capabilities. For example, in [10], the authors augment AODV with a new control message, called RREP_I, used as a route reply from the gateway on receiving a route request (RREQ) message to a destination outside the ad hoc network. The source node uses the RREP_I message to identify the gateway and select the best one, e.g. the nearest one. Only recently the research community has focused on the task of providing Internet connectivity while on the road [4-8]. In this case, vehicles with only short-range radios can use other vehicles (or roadside units), that have both shortrange and long-range connections, as mobile (or fixed) gateways to gain on board Internet access. Vehicular settings create more demanding requirements compared to the MANET environment; the most difficult challenge in the VANET scenario is to deal with frequent route interruptions due to
dynamic mobility of vehicles on the road. The frequent route failures can result in a significant amount of time (and signaling overhead) needed for repairing routes or searching for new ones. Successful prediction of route lifetimes can significantly reduce the number of route failures; in fact, predicted route lifetimes can be used to preemptively create new routes before existing ones fail. Approaches to predict route lifetimes have been used in the general context of MANETs [14, 15]; only very recently they have been proposed for vehicular ad hoc networks [8, 16], where they can rely on availability of location and velocity information to each node, which is assumed to be equipped with a global positioning system or other navigational instruments. In [8] a prediction-based routing protocol is specifically tailored to the mobile gateway scenario; it takes advantage of the knowledge of vehicles position and velocity, and of predictable vehicles mobility pattern on highways, to forecast how long a route will last between a vehicle and the Internet gateway. The analysis in [8] concerns the routing protocol performance, but it does not make any assumption on the MAC layer; this means that packets are sent without any interference from another node, and without accounting for dropping due to contention at the MAC layer. The main novelty of our proposal compared to previous approaches in literature is the attempt to create a unified framework to provide passengers in vehicles with QoS-enabled Internet connectivity. This requires (i) close cooperation among protocol layers in each “node” vehicle; (ii) augmentation of routing and MAC protocols in the VANET; (iii) enhancement of Internet gateway with QoS-aware functionality. 3 INTER-LAYER COOPERATION BEST GATEWAY SELECTION FOR
In this section, we discuss the main procedures, and the novel features of the proposed cooperative multi-layer framework. The reference scenario is reported in Figure 1.
Internet
Fixed Gateway
Mobile Gateway
Car-to-car communications
Figure 1: The reference scenario
UbiCC Journal – Volume 3
2
Vehicles equipped with IEEE 802.11 radios can use other vehicles (or roadside units) that have both 802.11 and long-range connections (e.g., cellular radio links or wired links) respectively as mobile (or fixed) gateways to gain on board Internet access. The focus is on non-safety applications with real time nature (such as audio or video streaming, or gaming), which can offer entertainment services to passengers on the road. 3.1 Basic Operation
-
use MAC and physical layers interaction to learn about QoS-enabled and reliable paths in the VANET; provide the gateways with enhanced capabilities to learn about or to negotiate QoS potential of connected networks. Multimedia Session Set up and Description
3.2
The basic operation of proposed framework and the main roles of all involved nodes are reported in Figure 2. It will be described in details in the following subsections.
Multimedia sessions can be initiated by passengers on cars using the Session Initiation Protocol (SIP) [17]. SIP is an application-layer control protocol, developed by the Internet Engineering Task Force (IETF), to establish, modify and terminate multimedia sessions or calls. Normally, at the session initiation, a SIP INVITE message is issued by the source node (the calling party) to the intended destination (the called party) through one or more SIP servers. The INVITE request contains the details of the type of session. A 200OK response is sent back by the called party when it decides to accept the call, finally an ACK message is sent for confirmation by the source, and the media session is established. In the reference scenario, illustrated in Figure 3, we assume that the source node is in the VANET and the destination node is outside the VANET.
2. Policy Negotiation PDP Gateway A
(SIP Proxy - PEP)
PDP 2. Policy Negotiation
5. INVITE to remote host
Figure 2: Basic framework
operation of
the proposed
1. RREQ + INVITE 1. RREQ+ INVITE 3. RREP
Gateway B
(SIP Proxy -PEP)
In the proposed architecture the gateway has a central role. It must assess the ability of both the external network and the vehicular network to match user preferences and QoS requirements. To this aim, it must be provided with capability of interpreting both high layer parameters (such as session description parameters, user preferences, and requirements) and low-level parameters (such as achievable throughput, delay, and estimated path lifetime). Furthermore, the gateway has to be provided with communication and negotiation capability towards the external network and also the VANET nodes. The main novelties of the proposed multi-layer cooperative approach are here listed and then explained in the following subsections: include high layer parameters (and not only network parameters) in the gateway selection process; relate gateway selection to both the VANET and the external network status and capabilities;
Figure 3: Session set up in the proposed framework SIP signaling messages have to flow through the Internet gateway to the external network. The proposed approach is that the gateway can exploit session information carried by SIP signaling to carry out mechanisms to negotiate QoS in the external network. In other words, the Internet gateway is proposed to act as a SIP proxy, and to implement functionality of a Policy Enforcement Point (PEP). It intercepts the INVITE message from the source vehicle (message 1 in Figure 3) and translates session description parameters into QoS requirements; then it starts a QoS negotiation phase with the Policy Decision Point (PDP) in the external network (message 2 in Figure 3). Signalling exchange between PEP and PDP can use standard protocols, such as COPS [18] as proposed in [19]. If enough resources are available in the external network and the user has the required privileges, then the policy negotiation succeeds, the gateway informs
UbiCC Journal – Volume 3
3
the source node (message 3 in Figure 3) and, after the source confirmation (message 4 in Figure 3), it forwards the INVITE packet to the intended destination (message 5 in Figure 3); otherwise the session ends. To augment SIP semantical expressiveness in describing a session (SIP session description only consists of codec parameters and requested bit-rates), we propose to use the extension of SDP (Session Description Protocol) to handle Capability Negotiation [9]. This working draft allows to enrich media/session description and negotiation capabilities for SIP-initiated multimedia sessions, and yet to maintain them simple enough to allow easy implementation and almost completely backward compatibility with the current SDP standard (RFC 2327). Besides classic session description parameter (such as IP-address and port, type of media stream, transport protocol), SDP Capability Negotiation allows for new capability attributes to be defined for a session, through suitable extension capability attributes. We propose to use these attributes to include high-layer user/application preferences to be interpreted by the gateway before checking QoS capability of the external network. As a simple example of additional session attributes we can consider: (i) preferred service providers the user has subscribed an agreement with; (ii) security and privacy level, representing the user requirements on data confidentiality; (ii) maximum cost the user is willing to pay for the required service, expressed through a suitable metric, and so on. 3.3 The Central Role of Gateway
The protocol’s basic operation of creating routes to the gateway in the VANET is similar to that of a reactive protocol, like AODV in [10]. When a vehicle needs to communicate to a location on the Internet, it checks its routing table for a route. If none exists, it broadcasts a route request (RREQ) packet. When the RREQ packet reaches a gateway with the desired route to the destination, the gateway has to process the request, and check QoS capability of both external and vehicular networks before generating the route reply (RREP) packet and send it back to the source node (message 3 in Figure 3). Gateways can perform this task because we suggest that route discovery packets embed all the information needed to check end-to-end QoS capability. The first main difference compared to previous routing approaches is that we propose the SIP INVITE message with SDP Capability Negotiation description to be embedded into the RREQ packets (message 1 in Figure 3) at session set up. The second difference is that RREQ packets also
carry information on the capability of the VANET to provide a QoS path from the source to the gateway. These low-layer parameters are collected while packets cross the VANET through cooperation of network, MAC, and physical layers (which is explained later in this paper), and give information on achievable throughput, delay, and expected route lifetime. Therefore, the RREQ packet contains a sequence number, source identification (ID), destination ID, some route parameters, and SDP capability negotiation parameters embedded in the payload. The gateway is enabled with capability to interpret all embedded information. The gateway, as a SIP proxy, interprets SDP data, and is aware of end-to-end QoS session requirements and user preferences. It also knows of the QoS capability of the VANET through route parameters, thereby it checks whether the external network can provide residual QoS, i.e., it can provide the minimum throughput and the maximum delay allowed in the external path to the destination. Therefore, the gateway starts a negotiation phase with the external network to assess both QoS constraints towards destination and application/user preferences. Only a gateway that successfully passes through the negotiation phase can inform the source node by sending back a RREP packet (message 3 in Figure 3). If multiple gateways reply, the source node chooses the gateway that is nearest in terms of hops. If the source gets multiple routes for the same gateway, it uses the route that has the maximum predicted route lifetime, as will be described later in the paper. To manage this, differently from legacy AODV [20], we introduce a control message, called Route Confirmation Message (CONFIRM), that is issued by the source towards the selected gateway (message 4 in Figure 3). Upon receiving a CONFIRM message, the gateway forwards the SIP INVITE to the external destination (message 5 in Figure 3). Candidate gateways, which do not receive a CONFIRM message before the expiration of a given timer, reset the current session initiation procedure. 3.4 Routing and MAC Protocols Cooperation
In our reference framework, to improve QoS capability in the VANET, routing choices at the network layer are undertaken through cooperation with the MAC layer. To carry out inter-layer cooperation we propose: the MAC protocol to provide estimation of expected delay (and throughput) achievable on the selected route; the routing protocol to select the route based on information from the MAC layer. Access control at the MAC layer is ruled by the
UbiCC Journal – Volume 3
4
EDCA contention function of IEEE 802.11e standard [11]. This choice is in agreement with studies carried out within the IEEE task group 11p that is standardizing a MAC protocol for VANET [3]. With EDCA, traffic flows have one of four access categories assigned that have different channel transmission priority; voice gets the highest priority, followed by video, and finally background and best effort traffic. Each wireless node in the VANET manages four queues, one for each 802.11e access category i (i=0...3). In each node, when a packet is ready for transmission and enters the Logical Link Control (LLC) layer, it is first buffered in one of the queues, waiting for being processed by the MAC layer and then transmitted on the air interface. In our framework, every node monitors two parameters for each queue i, namely DLLC ,i and
DMAC ,i . The first one represents the time spent by a
packet in a node, from the instant it enters the queue to the instant it is transmitted over the radio channel. DMAC ,i is the fraction of the DLLC ,i period that accounts for the delay due to the MAC protocol rules; it starts from the instant the packet reaches the head of the line and ends when it is transmitted on air. The DMAC,i delay contribution depends on many factors, such as physical transmission rate, random back-off interval, retransmissions attempts, and EDCA priority i. Furthermore, DMAC,i is related to the maximum throughput (MaxThi) achievable by a station transmitting at priority i through the equation PktSize , where PktSize is the packet MaxThi = DMAC ,i length. For the sake of simplicity we assume a fixed packet size in this paper. Therefore, whenever a frame is scheduled for transmission from the i-th queue, the time intervals DMAC , i and DLLC ,i are evaluated. The samples contribute to update the average values
E{DMAC ,i } and E{DLLC ,i } through an exponential
Maxe2eDelay , respectively carry the minimum throughput and the maximum delay that can be offered by the route. These values are hop-by-hop updated by nodes processing the RREQ packet. To include QoS parameters in the AODV routing protocol has been first suggested in [20], in this paper we propose a practical way to estimate the delay and the available throughput along the path. When the source node issues a RREQ packet, it initializes MinTh and Maxe2eDelay to the desired values specified by the user at session set up. Then, it also adds its traffic priority i and the packet length PktSize. Each node along the path reads and/or updates these fields through cooperation with the MAC layer: the Maxe2eDelay field is subtracted by the estimated DLLC,i value to account for time already spent in the path, and the achievable throughput is PktSize computed as and compared with the value DMAC ,i
stored in MinTh. Before forwarding the RREQ packet, each node checks whether the residual time is lower than the maximum delay tolerated and the achievable throughput on the current hop is higher than the minimum value specified by the user, according to equation (1):
PktSize MinTh ≥ DMAC , i Maxe2eDelay ≥ 0
(1)
weighted moving average with a smoothing factor α set to 0.4 after a wide tuning campaign. More details about MAC parameters estimation can be found in [21]. The computed average values E{DMac,i } and
E{DLLC ,i } will be used by the routing protocol to
Only if both the conditions are true, then the RREQ message is forwarded, otherwise it will be discarded. When the gateway finally receives RREQ packets, it can have information on the QoS capability of the VANET. Specifically, the MinTh and Maxe2eDelay fields contain, respectively, the minimum bit rate requirement and the residual delay allowed to be spent in the remaining path to the destination. Upon receiving this information, the gateway is able to start QoS negotiation with the external network, and reply back to the source, as described in section 3.3.
3.6 Route to the Gateway Maintenance
update route parameters and to choose the best route to the gateway, as detailed in the next subsection.
3.5 Qos-Aware Routing Toward the Gateway
To carry out QoS-aware route set up and maintenance in the VANET, we propose adding some low-layers route parameters in the RREQ packets. Two of them, namely MinTh and
The proposed routing protocol also differs from reactive protocols like AODV in the way that it proactively creates new routes before they break. Once the route is set up and the session is established, the routing layer of each VANET node continuously cooperate with DLC and Physical (PHY) layers to get information about the QoS performance of the route and about its reliability. Monitored parameters at the PHY layer of each node, in conjunction with the prediction algorithm (which
UbiCC Journal – Volume 3
5
is explained later in next subsection), are used to give the node a predicted lifetime for the route. If either QoS performance can no longer be met over the path or the predicted route lifetime is going to expire, then every node tries to preempt route failure and proactively seeks possibly better routes. By referring to Figure 4, after a route to the gateway is set up in the VANET, every node continuously monitors the RSSI (Received Signal Strength Indication) from its neighbors and computes the predicted route lifetime. When a node realizes that a link is rapidly deteriorating, then it labels the route as expiring and the link as critical in its routing table. The label expiring means that a route is going to be updated, while the label critical means that the link to the adjacent node is rapidly going to break. Then the node issues a Route-Alert packet upstream to the sender (message 3 in Figure 4) to trigger a Route Update procedure. Each node in the route modifies its routing table entry, by labeling the route as expiring, and keeps on forwarding the alarm message upstream to the sender. However, all the nodes continue to use the existing route to forward the data packets. The source node, upon receiving the Route-Alert packet, issues a SIP RE-INVITE message (with the same information of the original INVITE plus SDP description) and sends it embedded in a Route Update packet (message 4 in Figure 4).
8. RE-INVITE to remote host 9. New Data Flow Gateway
possibilities: (a) it is the same gateway which was already forwarding the user traffic (the route in the VANET has been repaired and the gateway is unchanged), or (b) it is a new gateway. In case (a), it continues to do its job as before; in case (b), it forwards the RE-INVITE message to the remote destination (message 8 in Figure 4). If procedure concludes successfully, the data traffic can flow between sender and receiver through the new gateway. As soon as the source receives data from the new gateway, it sends a BYE message to the old gateway (message 10 in Figure 4) to erase all routing entries labeled as expiring.
3.7 Estimating the Route Lifetime
Internet 5. Policy Negotiation
6. RREP
Internet
Gateway
4. Route Update + RE-INVITE 7. CONFIRM 10. BYE 3. Route Alert 1. Original Data flow 2. Low and Decreasing RSSI
Figure 4: Route maintenance signaling flows
A critical component of the proposed scheme is determining when path reliability is no longer acceptable (which generates a Route-Alert message). The path reliability can incorporate several criteria, such as signal strength, the age of a path, the number of hops, and rate of collisions [15]. In this paper, we restrict the path reliability to be a function of the signal strength (RSSI) of received packets. Since most route breaks can be ascribed to link failures due to node motion in the vehicular scenario, the signal strength offers the most direct estimate of the ability of the nodes to reach each other. When using RSSI as a path reliability indicator, it is important that signal power fluctuations, due to channel fading and multipath effects, do not generate erroneous warnings causing unnecessary floods of route update requests. Some established mechanisms are used in the cellular telephony field to solve this problem [15]. For example, maintaining an exponential average of the signal power (rather than triggering the mechanism based on a single packet) can be used to verify that the signal power drop was not due to fading or similar temporary disturbances. This is the approach we follow. All nodes in the VANET continuously measure the RSSI on each active link to their neighbors, and compute the RSSI variation according to equation (2):
∆RSSI (t actual ) = RSSI (t actual ) − RSSI t formerl t actual − t former
Intermediate nodes process Route Update packets like they do with RREQ packets, with the exception that they are not allowed to use cached routes to the destination. Therefore, intermediate nodes do not reply back to the source even if they have a route to the gateway, but they rather perform next-hop discovery if necessary. When searching for the new route, each node will discard routes that include links labeled as critical. All the gateways contacted, and able to handle the user traffic (message 5 in Figure 4), respond with a RREP packet (message 6 in Figure 4), and procedure goes on like described in section 3.3. When a gateway receives a CONFIRM packet from the source (message 7 in Figure 4), there are two
(
)
(2)
where tactual and tformer are the two time instants of current and previous RSSI measures, respectively. To filter out RSSI fluctuations in eq. (2), we consider an average ∆RSSI (t actual ) measure, which is obtained from ∆RSSI (t actual ) through an exponential weighted moving average with smoothing factor αRSSI. If ∆RSSI (t actual ) is greater than, or equal to, zero, the route is assumed to be reliable, otherwise, the RSSI is expected to have a decreasing trend. RSSI trend monitoring is used by each node to
UbiCC Journal – Volume 3
6
predict the route lifetime, according to the prediction algorithm here described. The algorithm exploits another additional field in the RREQ packet, namely ExpLifeTime that is used to carry information concerning the expected route lifetime. Initially, the source node sets the ExpLifetime field in the RREQ packet header equal to infinite. As the packet traverses the VANET to the gateway, each intermediate node does the following. Based on RSSI measurements from its adjacent nodes, it predicts the lifetime of the link between the two nodes using the prediction algorithm. If this value is smaller than the current lifetime mentioned in the RREQ packet, then the ExpLifetime field is changed to this value. Therefore, ExpLifetime= min(ExpLifeTime, plt), where plt is the predicted path lifetime. Else, the current value in the packet is left unchanged and forwarded toward the gateway. In this way, when the gateway gets a RREQ packet, the value of the ExpLifetime field that is indicated in the packet is the route’s predicted lifetime. The prediction algorithm performs plt computation based on both RSSI measurements and the receiver sensitivity S (the RSSI value, below which the receiver is not able to work properly), as shown in equation (3):
legacy algorithm is available on the web [23]. As a sample urban scenario, we considered a 1200m*600m map of the Reggio Calabria's seafront area, illustrated in Figure 5. Vehicles are supposed to travel at piecewise constant speeds, ranging between 5m/s and 12.5 m/s (18 km/h and 45 km/h); changes of velocity and direction can occur at each crossroad in the map, according to the mobility model proposed in [24]. The two-ray ground reflection model provided by ns2 has been used to simulate signal propagation in the channel.
Figure 5: The reference map for urban scenario
[RSSI (tactual ) − S ] + ∆RSSI (tactual ) ⋅ plt ≥ 0 → S − RSSI (t actual ) plt ≤ ∆RSSI (t actual )
(3)
The preemptive warning that triggers the Route update procedure is generated when the estimated lifetime of a monitored path drops below a threshold. The value of this threshold is critical to the efficiency of the algorithm. If the value is too low, there will not be sufficient time to discover an alternative path before the path breaks. However, if the value is too high, the warning is generated too early with the negative side-effect of unnecessary route updates: if the suspect path never breaks (e.g., the vehicles may change direction) and so the full life of the path currently in use is not exploited. After thorough simulations, the threshold has been set to 1.5 sec.
4 COMPARING LEGACY AND PROPOSED APPROACH
In this section we present a simulation campaign, carried out through ns2 (Network Simulator v2) [22] to assess the performance of the proposed multi-layer cooperative approach. We compare our solution, in the following referred to as multilayer approach, with the so-called legacy approach, which uses standard AODV routing protocol as in [10], and simply chooses the nearest gateway without any consideration on its capability to satisfy user requirements. The ns2 code used to implement the
Gateways or fixed relays have been placed at each intersection of a grid of 10 columns and 5 rows covering the reference urban area. Ten of the fifty fixed nodes are gateways and are connected to the wired Internet through links of different capacity, while the remaining nodes are only able to forward user traffic to the chosen gateway. The position of the gateways in the grid is randomly chosen and changes at each simulation run. Three kinds of gateways have been simulated whose main characteristics are reported in Table 1: Class 1 gateways act as broadband fixed points of presence for high demanding customers; Class 2 gateways are able to guarantee lower bit-rates but stricter delay constraints; Class 3 gateways offer more limited network resources. For the sake of simplicity, the achievable QoS in external networks is represented with fixed bit rates and delays. This assumption, although not totally realistic, allows us to focus on the main issue of this paper, i.e. how QoS, routing and gateway selection are performed within the access network, rather than investigating how they are accomplished outward. The other parameters in Table 1 account for the high-layer capabilities of the gateways (e.g., monetary cost of the connection, agreement with providers, and security degree). Two of the ten gateways belong to Class 1, two are Class 2 gateways, while the remaining six are Class 3 gateways. Ten vehicles among those moving in the simulation scenario, originate QoS-sensitive flows (voice and video) directed toward external hosts. QoS requirements of exchanged flows and user preferences are reported in Table 2. Voice traffic is modeled as a 8 Kbps Constant Bit Rate (CBR) flow; video streaming is modeled as a 192 Kbps CBR flow.
UbiCC Journal – Volume 3
7
The high-level requirements for each traffic class include the preferred provider, the maximum cost the user is available to pay for the connection, and the degree of security required.
Gateway type Class 1 Class 2 Class 3 External network QoS 1.5 Mbps 0.3 s 128 Kbps 0.05 s 56 Kbps 0.1 s Cost 10 3 2 Agreements with providers All Only providers and B All A 1 Sec. level 1 1
Table 1. Simulated gateways characteristics
Flow Max e2e delay 0.125s 0.5s Min. bitrate 8Kbps 192 Kbps Preferred Provider Prov. A Prov. B Max Cost 5 10 Sec. level 1 1
Voice Video
Table 2. Requirements of the QoS-sensitive flows
All other vehicles in the simulated scenario generate background interfering traffic (with lowpriority), which is likewise directed to the Internet. The interfering traffic load varies from 0 to 3 Mbps. Tables 1 and 2 show that the use of some gateways is prohibited to some traffic flows; for example, video flows can be served only through Class 1 gateways that are the only capable of providing the requested QoS (both Class 2 and Class 3 gateways do not match the bit rate requirement). Analogously, voice calls can pass through Class 2 or 3 gateways. Traffic flows access the radio channel in the VANET according to the rules of IEEE 802.11e MAC protocol [11]. Voice traffic achieves the highest priority, followed by video and finally by background traffic generated by the interfering vehicles. Simulations, each one lasting 200 seconds, are repeated 10 times by varying the mobility patterns, the position of available gateways, and the amount of background interfering traffic. Averaged measures are reported together with the relevant 95% confidence intervals. Figure 6 and 7 show the percentage of voice and video packets that have been delivered “in time” to the destination in the Internet. “In time” means within the committed end-to-end delay. This metric allows us to appreciate the degradation due to both lost packets and late delivered packets. Curves are reported when varying both the average speed of the vehicles and the interfering load. A general deterioration of performance (even if not dramatic) is visible when the vehicles speed increases, given to the higher difficulty of maintaining a route to the
gateway. From the results shown, the proposed multilayer framework outperforms the legacy one in any simulated case for video flows. This is generally true also for voice flows even if, in this case, the gain is sometimes lower than in the video case. In fact, the legacy approach has more chances that the selected gateway to forward voice traffic (i.e., any closest gateway) is also able to satisfy user and QoS requirements (eight of the ten gateways are good ones for voice); while this is not true for video flows whose requirements can be matched only by Class 2 gateways (two of the ten gateways are good ones). Furthermore, Figures 6 and 7 show that the performance of the multilayer approach when there is no interfering traffic is dramatically higher than the legacy approach in the same traffic condition. This is because of the smart selection operated by the multilayer approach that is able to reach the right gateway through a good and reliable path in the VANET. When the interfering traffic increases, obviously the performance decreases also due to the fact that to find and maintain a good and reliable path to the best gateway is more difficult. As shown in Figure 8, the multilayer approach chooses longer paths in the VANET compared to the legacy one. This is because the legacy approach can often find a (any) gateway at one hop distance, while the multilayer approach searches for the best gateway (that is rarely the nearest one).
Percentage of in-time video packets
100 80 60 40 20 0 5 6 7 8 9 Speed (m/s) 10 11 12 13
legacy no interf. legacy 1Mb/s interf. legacy 2Mb/s interf. legacy 3Mb/s interf. multilayer no interf. multilayer 1Mb/s interf. multilayer 2Mb/s interf. multilayer 3Mb/s interf.
Figure 6: Percentage of video packets in-time delivered to destination
Percentage of in-time voice packets
100 80 60 40 20 0 5 6 7 8 9 Speed (m/s) 10 11 12 13
legacy no interf. legacy 1Mb/s interf. legacy 2Mb/s interf. legacy 3Mb/s interf. multilayer no interf. multilayer 1Mb/s interf. multilayer 2Mb/s interf. multilayer 3Mb/s interf.
Figure 7. Percentage of voice packets in-time delivered to destination
UbiCC Journal – Volume 3
8
2.5
2
1.5
1 legacy no interf. legacy 1Mb/s interf. legacy 2Mb/s interf. legacy 3Mb/s interf. multilayer no interf. multilayer 1Mb/s interf. multilayer 2Mb/s interf. multilayer 3Mb/s interf. 5 6 7 8 9 Speed (m/s) 10 11 12 13
0.5
0
Figure 8. Average number of hops in the VANET
A further evidence of this fact is observable in Figures 9 and 10 that show the percentage of packets which is delivered to a gateway in the VANET. The legacy approach delivers almost all packets to a (any) gateway in the VANET. Unfortunately, a very small percentage of these packets will be delivered to the intended destination within the target end-to-end delay.
1
Percentage of video packet delivered to a gateway
0.8
0.6
0.4 legacy no interf. legacy 1Mb/s interf. legacy 2Mb/s interf. legacy 3Mb/s interf. multilayer no interf. multilayer 1Mb/s interf. multilayer 2Mb/s interf. multilayer 3Mb/s interf. 5 6 7 8 9 Speed (m/s) 10 11 12 13
packets in the VANET. Signaling packets included in the overhead computation are all the packets needed at the network layer to set up and maintain the route to the gateway (RREQ, RREP, RERR, and Route Alert messages). Both approaches show a general decrease of the overhead when the interfering traffic load increases and a general increase of the overhead when the vehicles speed increases. The former effect is due to the fact that, when the interfering traffic is higher the number of totally generated packets in the VANET increases more rapidly than the number of signaling packets, thus the fraction of overhead is computed over a higher number of totally generated packets. The latter effect is due to a higher route breakage probability when the speed of mobile nodes increases. This effect is however less evident when the interfering traffic increases, because at the increasing of the interfering traffic also increases the number of route breakages due to network congestion rather than to the mobility of the nodes. The comparison of multilayer and legacy approaches shows that the multilayer approach introduces lower overhead than the legacy approach when no interfering traffic is considered, then when the interfering traffic increases the overhead slightly increases, but it keeps on values that are comparable to the legacy one. The better behavior of multilayer approach compared to the legacy one in the case of zero interferers is because of its choice of more reliable (i.e., with a longer lifetime) paths to the gateway.
0.2
Average number of Hops in the Vanet
0.2
0
0.15
Protocol overhead
Figure 9. Percentage of video packets delivered to a gateway in the VANET
1
0.1
Percentage of voice packets delivered to a gateway
0.05
0.8
legacy no interf. legacy 1Mb/s interf. legacy 2Mb/s interf. legacy 3Mb/s interf. multilayer no interf. multilayer 1Mb/s interf. multilayer 2Mb/s interf. multilayer 3Mb/s interf. 5 6 7 8 9 Speed (m/s) 10 11 12 13
0
0.6
Figure 11: Protocol overhead
0.4 legacy no interf. legacy 1Mb/s interf. legacy 2Mb/s interf. legacy 3Mb/s interf. multilayer no interf. multilayer 1Mb/s interf. multilayer 2Mb/s interf. multilayer 3Mb/s interf. 5 6 7 8 9 Speed (m/s) 10 11 12 13
5
CONCLUSIONS
0.2
0
Figure 10. Percentage of voice packets delivered to a gateway in the VANET
Finally let us consider the protocol overhead reported in Figure 11 that shows the fraction of signaling packets over the total number of generated
The reference scenario analyzed in this paper considers moving vehicles that gain Internet connectivity while on the road, through fixed or mobile gateways in their radio proximity. The proposed framework, which is based on inter-layer cooperation, provides mobile passengers with QoSenabled on board connectivity for entertainment purposes. These tasks are performed through (i) setting up
UbiCC Journal – Volume 3
9
multimedia sessions from VANET nodes; (ii) reactively building QoS network paths in the VANET; (iii) selecting the best available gateway for outward transmission, according to network resource availability and compliance with user/application requirements, and (iv) constantly maintaining and updating routes to the gateways. Simulations in urban scenarios showed that the proposed approach achieves improved performance, mainly in terms of effectiveness of procedures of path-to-the-gateway discovery and maintenance, and end-to-end QoS provisioning.
REFERENCES
[1] K. D. Wong, K. Tepe, W. Chen, M. Gerla: Intervehicular communications, IEEE Wireless Communications, Vol. 13, No. 5, (2006) [2] M. Wellens, B. Westphal, P. Mahonen: Performance evaluation of IEEE 802.11-based WLANs in vehicular scenarios, Proceedings of IEEE Vehicular Technology Conference, VTC Spring, (2007) of Project IEEE 802.11p, [3] Status http://grouper.ieee.org/groups/802/11/Reports/tg p_update.htm [Cited on: Sept. 2007], (2007) [4] M. Bechler, O. Storz, W. Franz, L. Wolf: Efficient discovery of internet gateways in vehicular communication systems, Proceedings of IEEE Vehicular Technology Conference, VTC Spring, (2003) [5] J. Ott, T. Kutscher: Drive-thru Internet: IEEE 802.11b for ‘Automobile’ users, Proc. IEEE INFOCOM, (2004) [6] A. Iera, A. Molinaro, S. Polito, G. Ruggeri: Endto-end QoS provisioning in 4G with mobile hotspots, IEEE Network Magazine, Vol. 19, No. 5, pp. 26-34, (2005) [7] V. Bychkovsky, B. Hull, A. K. Miu, H. Balakrishnan, S. Madden: A measurement study of vehicular internet access using in situ Wi-Fi networks, Proc. ACM MOBICOM (2006) [8] V. Namboodiri, L. Gao: Prediction-based routing for vehicular ad hoc networks, IEEE Transactions on Vehicular Technology, Vol. 56, No. 4, pp. 2332-2345, (2007) [9] F. Andreasen: SDP capability negotiation, IETF MMUSIC Working Group, Internet draft draftietf-mmusic-sdp-capability-negotiation-06.txt, (2007) [10] C. E. Perkins, J. T. Malinen, R. Wakikawa, A. Nilsson, A. J. Tuominen: Internet connectivity
for mobile ad hoc networks, Wireless Communications and Mobile Computing, no. 2, pp. 465-482 (2002) [11] IEEE 802, part 11: Wireless LAN medium access control (MAC) and physical layer (PHY) specifications: MAC enhancements for quality of service (QoS), IEEE std 802.11e, (2005) [12] H. Ammari, H. El-Rewini: Integration of mobile ad hoc networks and the Internet using mobile gateways, Proceedings of International Parallel and Distributed Processing Symposium (2004) [13] M. K Denko, C. Wei: An architecture for integrating mobile ad hoc networks with the Internet using multiple mobile gateways, Canadian Conference on Electrical and Computer Engineering, (2005) [14] W. Su, S. Lee, M. Gerla: Mobility prediction and routing in ad hoc wireless networks, International Journal of Network Management, Vol. 11, No. 1, pp. 3–30, (2001) [15] T. Goff, N. B. Abu-Ghazaleh, D. S. Pathak, R. Kahvecioglu: Preemptive routing in ad hoc networks, Journal of Parallel and Distributed Computing, Vol. 63, No. 2, pp. 123–140 (2003) [16] M. Mabiala, A. Busson, V. Veque: Inside VANET: hybrid network dimensioning and routing protocol comparison, Proceedings of IEEE Vehicular Technology Conference, VTC Spring, (2007) [17] J. Rosenberg et al.: SIP: Session Initiation Protocol, IETF RFC 3261 (2002) [18] D. Durham et al.: The COPS (Common Open Policy Service) protocol, IETF FRC 2748 (2000) [19] S. Salsano, L. Veltri: QoS control by means of COPS to support SIP-based applications, IEEE Network, Vol. 16, No. 2, pp.27-33 (2002) [20] E. M. Belding-Royer, C. E. Perkins: Evolution and future directions of the Ad hoc On-Demand Distance Vector routing protocol, Ad hoc Networks Journal, Vol. 1, No. 1, pp. 125-150, (2003) [21] A. Iera, A. Molinaro, G. Ruggeri, D. Tripodi: Dynamic priority assignment in IEEE 802.11e ad-hoc networks, Proceedings of IEEE Global Telecomm. Conference (GLOBECOM), (2005) [22] http:www.isi.edu/nsnam/ns [23] http://www.telecom.lth.se/Personal/alexh/ [24] A. K. Saha, D. B. Johnson: Modeling mobility for vehicular ad-hoc networks, Proceedings. of ACM Workshop on Vehicular Ad hoc networks, (2004)
UbiCC Journal – Volume 3
10
Towards Efficient Routing in Vehicular Ad Hoc Networks
Moez Jerbi*, Sidi-Mohammed Senouci* and Yacine Ghamri-Doudane**
*France Telecom R&D, Core Network Laboratories, Lannion, France **Networks and Multimedia Systems Research Group, ENSIIE, Evry, Cedex, France
Based on a localization system like the GPS (Global Positioning System), our solution aims to efficiently relay data in the network considering the real time road traffic variation and the characteristics of city environments. GyTAR assumes then the existence of an accurate traffic-information system that it requires. To this end, we also propose in this work a completely decentralized mechanism for the estimation of traffic density in city-roads called IFTIS for InfrastructureFree Traffic Information System. Note that, although it has been designed to operate with GyTAR, IFTIS is a completelty independent component which could be used for any other purpose requiring road density estimation. Indeed, IFTIS could be adopted, for instance, to be used in real-time traffic congestion warning systems, leveraging on the proposed distributed mechanism that provides updated traffic information to drivers. The rest of the paper is structured as follows. Section 2 presents existing approaches on routing in VANET and details the principles of GyTAR. Section 3 describes the mechanism used in IFTIS to provide the information about vehicular traffic between two junctions. Section 4 presents simulation setting and results. Finally, conclusion and future work are summarized in Section 5. II. IMPROVED GREEDY TRAFFIC AWARE ROUTING PROTOCOL A. Routing in VANET Recently, some routing protocols specific to VANETs have been proposed. In the following, we present the most important ones: GSR, A-STAR, and GPCR. 'GSR' [1] (Geographic Source Routing) has been recently proposed as a promising routing strategy for vehicular ad hoc networks in city environments. It combines position-based routing with topological knowledge. The simulation results, with the use of realistic vehicular traffic in city environments, show that GSR outperforms topology-based approaches (DSR and AODV) with respect to delivery rate and latency. In another study [2], the same authors have shown, for highway scenarios, that routing approaches using position information, e.g., obtained from on-board GPS receivers, can very well deal with the mobility of the vehicles. 'A-STAR'[3] (Anchor-based Street and Traffic Aware Routing) is a position-based routing scheme designed specifically for IVC in city environments. It features the novel use of city bus route information to identify anchor paths of higher connectivity so that more packets can be delivered to
Abstract— Multi-hop data delivery through Vehicular Adhoc Networks is challenging since it must efficiently handle rapid topology changes and a fragmented network. This paper proposes a new intersection-based geographical routing protocol called GyTAR (improved Greedy Traffic Aware Routing protocol) and capable to find robust routes within city environments. GyTAR consists of two modules: (i) dynamic selection of the junctions through which a packet must pass to reach its destination, and (ii) an improved greedy strategy used to forward packets between two junctions. GyTAR assumes the existence of an accurate traffic-information system that it requires to select paths with high connectivity. To address this issue, we also propose a completely decentralized mechanism for the estimation of traffic density in city-roads called IFTIS for Infrastructure-Free Traffic Information System. The proposed routing protocol shows significant performance improvement in a comparative simulation study with other routing approaches. Index Terms— Vehicular Ad hoc Network, Greedy Routing,
Vehicular Traffic Estimation, Performance Measurements
I. INTRODUCTION Inter-vehicle communication is a fast growing research topic in the academic sector and industry. Through this kind of communication, vehicles are able to communicate with each other by using wireless technology like WLAN. As a result, they can be organized in vehicular ad hoc networks (VANETs). VANETs are an instantiation of mobile ad hoc networks (MANETs). MANETs have no fixed infrastructure and instead rely on ordinary nodes to perform routing of messages and network management functions. However, vehicular ad hoc networks behave in different ways than conventional MANETs. Driver behavior, mobility constraints, and high speeds create unique characteristics of VANETs. These characteristics have important implications for designing decisions in these networks. Thus, numerous research challenges need to be addressed for inter-vehicule communications to be widely deployed. For example, routing in conventional mobile ad hoc networks is a challenging task because of the network's dynamic topology changes. Numerous studies and proposals of routing protocols have been conducted to relay data in such a context; however these solutions can not be applied to the vehicular environment due to the specific constraints and characteristics of VANETs. In this work, we present a novel geographical routing protocol for vehicular networks in city environments called GyTAR: improved Greedy Traffic Aware Routing protocol.
UbiCC Journal – Volume 3
11
their destinations successfully. A new recovery strategy for packets routed to a local optimum1 was also proposed, consisting of the computation of a new anchor path from the local maximum to which the packet is routed. The Greedy Perimeter Coordinator Routing (GPCR) protocol [4] has been designed to deal with the challenges of city scenarios. It does not require any global or external information such as a static street map. The main idea of GPCR is to forward data packets using a restricted greedy forwarding procedure. That means when choosing the next hop, a coordinator node (a node on a junction) is preferred to a non-coordinator node, even if it is not the closest node to destination. In summary, existing data delivery schemes use a position-based routing strategy, which scales better in a highly dynamic and fragmented network as VANET. In addition, most of the current routing proposals are spatial aware since spatial information such us streets map of a city is utilized to assist in making routing decisions. In the following sub-sections, we give detailed description of our approach and present its added value compared to other existing vehicular routing protocols. B. GyTAR Assumptions GyTAR considers that each vehicle in the network knows its own position thanks to the use of GPS2. Furthermore, a sending node needs to know the current geographical position of the destination in order to make the routing decision. This information is assumed to be provided by a location service like GLS (Grid Location Service) [7]. Moreover, we consider that each vehicle can determine the position of its neighboring junctions3 through pre-loaded digital maps, which provides a street-level map. The presence of such kind of maps is a valid assumption when vehicles are equipped with on-board navigation system. We also assume that every vehicle is aware of the vehicular traffic (number of vehicles between two junctions). This information can be provided by IFTIS: a completely decentralized mechanism for the estimation of traffic density in a road traffic network which will be described in section III. C. GyTAR Overview GyTAR is a new intersection-based geographical routing protocol capable to find robust routes within city environments. It consists of two modules: 1) Junction selection In GyTAR, the different junctions the packet has to traverse in order to reach the destination are chosen dynamically and one by one, considering both vehicular traffic variation and distance to destination: when selecting the next destination junction, a node (the sending vehicle or an intermediate vehicle in a junction) looks for the position of the neighboring junctions using the map. A score is given to each
1 Situation where there is no neighbor of the forwarding node s, which is closer to destination than s itself. 2 The popularity of GPS on vehicles in today's world makes this assumption acceptable. 3 A place where two or more roads join or meet.
junction considering the traffic density and the curvemetric4 distance to the destination. The best destination junction (the junction with the highest score) is the geographically closest junction to the destination vehicle having the highest vehicular traffic. To formally define this score, we need the following notations: - J: the next candidate junction. - I: the current junction - Dj: the curvemetric distance from the candidate junction J to the destination. - Di: the curvemetric distance from the current junction to the destination. - Dp = Dj/Di (Dp determines the closeness of the candidate junction to the destination point) - Between junction I and junction J: Nv : total number of vehicles between I and J, Nc : number of cells5 between I and J, Navg: average number of vehicles per cell (Navg = Nv/Nc), Ncon: constant which represents the ideal connectivity degree we can have within a cell. - α, β: used as weighting factors for the distance and vehicular traffic respectively (with α + β = 1). Hence, score (J) = α × [ 1 - Dp] + β × [ min (Navg/Ncon , 1) ]
Figure 1. Selecting junctions in GyTAR.
Figure 1 shows an example of how the next junction is selected on a street. Once vehicle A receives a packet, it computes the score of each neighboring junction. Considering its curvemetric distance to the destination and the traffic density, junction (2) will have the highest score. Then, it will be chosen as the next anchor. 2) Forwarding data between two junctions Once the destination junction is determined, the improved greedy strategy is used to forward packets towards the selected junctions. For that, all data packets are marked by the location of this junction. Each vehicle maintains a neighbor table in which, the position, velocity and direction of each neighbor vehicle are recorded. This table is updated through hello messages exchanged periodically by all vehicles. Thus, when a packet is received, the forwarding vehicle computes the new predicted position of each neighbor using the recorded information (velocity, direction and the latest known position), and then selects the next hop neighbor (i.e. the closest to the destination junction).
This term describes the distance measured when following the geometric shape of a road. 5 The cell is determined based on the wireless transmission range of vehicles.
4
UbiCC Journal – Volume 3
12
Figure 3 –Relaying Local Density Information between groups.
In the following sub-section, we introduce the distributed mechanism for the estimation of road-traffic density. B. Generating, Forwarding & Analysing CDP
Figure 2. Forwarding data between two junctions using improved greedy strategy.
This approach is illustrated in Figure 2, where vehicle (1), which is moving in the same direction as the forwarding vehicle with a speed greater than vehicle (2), will receive the forwarded packet since at time (t2), it is the closest to the next junction. However, without using prediction, the forwarding vehicle would choose vehicle (4) as the next hop instead of vehicle (1) since it was the closest to the destination junction at time t1 (last time the neighbors table was updated). 3) Recovery strategy Despite the improved greedy routing strategy, the risk remains that a packet gets stuck in a local optimum. Hence, a recovery strategy is required. The repair strategy of GyTAR is based on the idea of "carry and forward": the forwarding vehicle of the packet in a recovery mode will carry the packet until the next junction or until another vehicle, closer to the destination junction, enters/reaches its transmission range. III. INFRASTRUCTURE-FREE TRAFFIC INFORMATION SYSTEM IFTIS is a completely decentralized mechanism for the estimation of traffic density in a road traffic network. This decentralized approach revolves around the core idea of information relaying between groups of vehicles rather than individual vehicles. More precisely, vehicles are arranged into location-based groups. Local density information is then relayed between groups using Cells' Density Packet (CDP). A. Group Formation Each road (section of street between two intersections) is dissected into small fixed area cells, each defining a group. Note that the cell size depends on the transmission range of vehicles (around 300m) and the cell ID depends on the road ID. Cells, and hence groups, overlap in such a way that any vehicle moving from one cell to the next belongs at least to one group. The closest vehicle to the cell center is considered as group leader for a given duration. This is illustrated in Figure 3 where group leaders are vehicles which are within the small circle around the cell center.
1) What is a CDP? The Cells' Density6 data Packet (CDP) provides the cell density of a given road. As illustrated in Fig. 4, CDP also contains fields identifying the road ID, transmission time7, and the list of route anchors (position of cells center).
Cells Data Packet (CDP)
Road ID Time
Cell ID
Cell 's Center (Position)
Cell's Density
Figure 4 - CDP message format –
2) Who generates the CDP? The CDP is generated by vehicles which have already been group leaders. In other words, only a vehicle which has already updated a CDP message will generate the new CDP. It only does so when it reaches a road intersection (i.e. before leaving the road). This is to control the generation of CDP messages, avoiding scalability issues. When initiating the CDP, such vehicle records the road ID, the transmission time and a list of anchors through which the packet has to pass while traveling to the other intersection. Then, it sends it backward.. 3) How the CDP is forwarded backward and who updates it? The CDP header includes a limited list of anchors corresponding to the position of the cells’ centers. Then, the CDP is forwarded towards the first anchor on the basis of greedy forwarding (the forwarding vehicle selects among all its neighbors the closest vehicle to the next anchor). When it is reached, the group leader (closest vehicle to the cell center) updates the CDP by including the density of the corresponding cell (the number of its neighbors which belong to the corresponding road8) and then forwards it towards the next anchor, and so on. When the last anchor (the destination intersection) is reached, the CDP is propagated to vehicles which are around the intersection. The IFTIS algorithm is illustrated in Fig 5. Arriving at the traffic junction, the CDP packet contains the information of the cell-density of all the traffic groups in the road. Having this information is advantageous for determining if the cell is over-populated, for example, due to a traffic jam
By density, we mean the number of vehicles within the cell. Note that all the vehicles are synchronized by GPS. 8 This information is already available in the neighbor table (built and updated thanks to the periodic exchange of hello messages by all vehicles)
7 6
UbiCC Journal – Volume 3
13
or accident. Perhaps, the overall traffic density will not be high for the road, but for a particular cell, the density level maybe very high, indicating some traffic problem.
Notation:
CDP: the CDP packet to forward fv: the forwarding vehicle, Ibegin: intersection at the beginning of the road section Iend: intersection at the end of the road section Ni1:number of vehicles on cell i moving from Ibegin to Iend, Ni2:number of vehicles on cell i moving from Iend to Ibegin,
Table 1: Simulation setup
SIMULATION / SCENARIO Simulation Time 200s Map Size 2500 x 2000 m2 Our own realistic Mobility Model mobility model Number of 16 intersections Number of roads 26 MAC / ROUTING MAC protocol 802.11 DCF Channel Capacity 2 Mbps
Trans. Range
~266 m
Traffic Model
Number of vehicles
100-300
Packet sending rate Weighting factors (α;β)
15 CBR connections 0.1 – 1 second
(0.5;0.5)
Algorithm: A vehicle fv receives the packet CDP: if fv is not around Ibegin then if fv is a group leader // fv is in the red zone of Cell i then Update CDP - Fill the density of cell i Ni = Ni1 + Ni2; - NextAnchor = center of cell i+1 End if Select next Hop & forward CDP - fv selects neighbors (N)moving towards Ibegin - if ∃ v ∈ N closer to NextAnchor - then fv forwards CDP to v else // fv is the closest vehicle to NextAnchor Store CDP and carry it else //the CDP reaches Ibegin Broadcast CDP around Ibegin end if Figure 5 - Algorithm: Forwarding CDP Packet –
Vehicle velocity (city)
30-50±5 Km/h
Data packet size
128 bytes
The algorithms are compared under various data transmission rates and various vehicle densities. Detailed analysis of the simulation results are given in the following.
Figure 6 –Delivery ratio Vs Packet Sending Rate (300 nodes).
4) Analyzing CDP The CDP packets are received by the vehicles traversing through the junctions. These vehicles analyze the CDP packet and calculate the density for the respective road from which the CDP was received. The CDP packet is analyzed with respect to the group density information recorded in the packet by each group leader. The analysis of the information from each group (for example, the mean and variance of the cells density) will provide the overall density of the road. Hence, when using GyTAR as routing protocol, vehicles around a junction receive CDP and based on the analysis of its content, they calculate the score corresponding to the road density. IV. SIMULATION RESULTS To evaluate the performance of our proposed protocol, we used the Qualnet simulator [5]. We implemented two versions: B-GyTAR (Basic GyTAR without local recovery: a packet is simply dropped when it encounters a local maximum situation), and GyTAR with the recovery method. We also implemented a version of the position-based vehicular routing protocol GSR [1] since there is not any publicly available implementation of the protocol. B-GYTAR and GyTAR are then compared to GSR and LAR [6]. All the key parameters of our simulation are summarized in the following table:
In Fig. 6, we present the obtained packet delivery ratio of the four studied protocols. Figure 6 shows that GyTAR achieves the highest packet delivery ratio for the different CBR rates (a relative improvement of over 9% than GSR). This is mainly because in GyTAR, the path is determined progressively following road traffic density and urban environment characteristics. Hence, a packet will move successively closer towards the destination along streets where there are enough vehicles to provide connectivity. While in GSR, a complete sequence of waypoints is computed before the packet is originally transmitted by the source and without considering the vehicular traffic. Consequently, some data packets can not reach their destination due to a problem of connectivity on some sections of streets. LAR achieves a lower delivery ratio than GyTAR because it uses a route discovery mechanism. Consequently, some data packets can not reach their destination because it is very difficult to maintain an end-to-end connection in the vehicular environment (frequent topology change and network fragmentation).
UbiCC Journal – Volume 3
14
[5]
Scalable Network Technologies http://www.scalable-networks.com.
Inc.,
Qualnet
simulator,
[6]
Y. Ko and N. Vaidya, "Locaton-aided routing (LAR) in mobile ad hoc networks", ACM/IEEE MOBICOM'98, Dallas, USA, August 1998, p. 66-75. J. Li, J. Jannotti, D. De Couto, D. Karger, and R. Morris, "A scalable location service for geographic ad hoc routing", ACM/IEEE MOBICOM'2000, pp. 120.130, 2000.
[7]
Figure 7 –End-to-End Delay Vs Nodes Number (5 packets/ second).
As shown in Figure 7, GyTAR and B-GyTAR achieve a much lower end–to-end delay than LAR and GSR in all configurations. This is because in GyTAR, the number of hops involved to deliver packets is reduced due to the improved greedy strategy used to forward packets between two junctions, and also because GyTAR does not need to keep track of an end-to-end route before sending data packets: the route is discovered progressively when relaying data packets from source to destination. In contrast, the geographical routing protocol LAR uses a route discovery mechanism which causes longer delays. Delay of GSR is higher than GyTAR because packets whose delivery was suspended are stored in the buffer for longer time than in GyTAR's suspension buffer.
V. CONCLUSION AND FUTURE WORK In this paper, we proposed GyTAR, a novel routing algorithm for vehicular ad hoc networks, and we measured its performance in comparison to other algorithms existing in the literature. Simulation results show significant performance improvement in terms of packet delivery ratio, end-to-end delay. We also proposed IFTIS, a completely distributed traffic information system, capable to monitor the city traffic condition and distribute such information to vehicles around junctions. We are currently studying the impact of IFTIS approach in vehicular ad hoc routing protocols like GyTAR to analyze the performance gains. REFERENCES
[1] C. Lochert, H. Hartenstein, J. Tian, D. Herrmann, H. Füßler, M. Mauve, "A Routing Strategy for Vehicular Ad Hoc Networks in City Environments", IEEE Intelligent Vehicles Symposium (IV2003), pp. 156-161, Columbus, OH, USA, June 2003. H. Füßler, M. Mauve, H. Hartenstein, M. Käsemann, and D. Vollmer, "Location-based routing for vehicular ad hoc networks", student poster, ACM Mobicom ’02, Atlanta, Georgia, USA, 2002. B.-C. Seet, G. Liu, B.-S. Lee, C. H. Foh, K. J. Wong, K.-K. Lee, "ASTAR: A Mobile Ad Hoc Routing Strategy for Metropolis Vehicular Communications". NETWORKING 2004, 989-999. C. Lochert, M. Mauve, H. Füßler, H. Hartenstein, "Geographic Routing in City Scenarios", MobiCom 2004.
[2]
[3]
[4]
UbiCC Journal – Volume 3
15
½
ÖÓ××¹Ä Ý Ö
Ö Ñ ÛÓÖ Ò Î
º ÊÙ
ÓÖ
×Ø ÁÒØ ÖÒ Ø
××
ÙÐ Ö Æ ØÛÓÖ ×
Ö ¸ ˺ ÈÓÐ ØÓ¸
Ø ÖÖ Ò
º ÅÓÐ Ò ÖÓ¸ Ê Ó Ð Ö ¼ ¼ Ê
º Á Ö ¹ Ó ºÁºÅº ºÌº Ð Ö ÁØ Ðݺ ÒØÓÒ Óº Ö µÙÒ Ö
º Ø
ÍÒ Ú Ö× Ø Î ¹Ñ д Ù× ÔÔ ºÖÙ
Å
Ö Þ ÐÐ ¸ ÄÓ
Ð Ø Ö¸ × Ö
Ó
Î ØÓ¸
ÓºÔÓÐ ØÓ¸
ÒØÓÒ ÐÐ ºÑÓÐ Ò ÖÓ¸
Ð ×ØÖ Ú
Ø
ÙÐÖÓÑÒØ×× ÛÒÐÐ×ÐÝ×Ø ×
ÐÓÖ ÖÐÝ ×ÒÑÐ ÚÖ ÔÔÐØ
× ØØ ÓÒ× ÝÒ Ø ÒØ Ó Ö Ö ØÛÓÖ ØÓÖ ÓÖ ØÓÒ ØÓ ×Ù
ÁÒØ ÖÒ Ø¸ Ð ÒØ ÔÖÓÚ ×
Ð ÉÓË
ÓÒ×Ø
¹
ÓÒÒ
Ø Ø Ðݸ Ø Ò ×Ô Ø Ó Ø × ×ØÖÓÒ Ö ÕÙ Ö Ñ ÒØ׸ Ò¹ ØÓ ÍÒ ÓÖØÙÒ Ø
ÓÒÒ
Ø Ú ØÝ Ò Î Æ Ì × Ú ÖÝ
×ÙÔÔÓÖغ ÓÒÔÐ ÁÒØØÚÖÒØ ÁÒ Ø × ÖÔÚÔ ØÖ¸ Û Ù Ñ×
Ù×× Ø×ÓÑÓ
ÖÓ×׹РÝÐÐÖ ÒÔÖ Ò
Ò
Ø ÔÐÓÝ
ÓÙÐ × º ÔÖÓØÓ
ÓÐ׸ ×Ù
× ËÁÈ ØÓÒ Û
Ø ÓÒ ÐÔØÚҹРÒØ Ø ÔÔÐ ÐÝ
ÛÒØ ØÇ Î ×ØØ ØÚ ÐÒ ØÛÓÖ ÖÒÚ Øи ØÓ ÔÖÓÚ Ú
ÙÐ Ö Ù× Ö× Ð ÁÒØ Ð
×׺
Ø Û Ý × Ð ÐÝ ØÓ Ö ÖÓÑ ÔÔÐ
Ø ÓÒ ØÓ ÔÔÐ
Ø ÓÒ¸ Ø ×
ÓÑÔÐ
Ø Ò Ø ×
Ò Ö Óº ÁÒ
ظ Ø Û Ý× Ú Ð Ð Ò
ÖØ Ò Ö
Ò ÓÛÒ Ý Ö ÒØ ÔÖÓÚ Ö׸
Ó Ö Ò Ø Ö ×Ô
ÔÖ
Ò ¸ ÉÓ˸ Ò Ñ Ò ×ØÖ Ø Ú ÔÓÐ ¹
× ØÓ Ö ×Ø Ö Ù× Ö׺ × Ò Ü ÑÔÐ ¸ Ð Ø Ù× ×ÙÔÔÓ× Ø Ø Ù× Ö × Ò Ò Ö Ñ ÒØ Û Ø ØÛÓ × ÖÚ
ÔÖÓÚ Ö׸ Ð Ø³× × Ý ËÈ Ò ËÈ º ËÈ Ó Ö×
Ô Ö Ò ×Ø ÓÖØ ØÖ
Ð Ú ÖÝ ËÈ ÐÐÓÛ× ÓÖ ×ØÖ Ò ÒØ ÉÓË ×ÙÔÔÓÖØ Ø Ö Ö º Ì Ù× Ö Û ÐÐ Ð ÐÝ ØÖ Ò×Ñ Ø ×Ø ÓÖØ ØÖ
Ø ÖÓÙ Ø Û Ý ÐÓÒ Ò ØÓ ËÈ ¸ Ò ÉÓË Ñ Ò Ò ÓÛ× Ø ÖÓÙ Ø Û Ý ÐÓÒ Ò ØÓ ËÈ º ÍÒ ÓÖØÙÒ Ø Ðݸ Áº ÁÒØÖÓ Ù
Ø ÓÒ Ø Ø Û Ý × Ð
Ø ÓÒ ÔÖÓ
ÙÖ × ÒÓØ × × ÑÔÐ × ×Ø Ø × Ò Ò ÔÐÓÝÑ ÒØ Ó Ú
ÙÐ Ö Ò ØÛÓÖ × × Ö ¹ ÓÚ ¸ × Ò
Ø
Ò
Ø Ð×Ó Ý ´ µ Ø ÐÓ
Ø ÓÒ Ó
ÒØ ÒÒÓÚ Ø ÓÒ Ò Ø Û Ö Ð ××
ÓÑÑÙÒ
Ø ÓÒ× ×
Ò Ö Óº Ø Ø Û Ý¸ Ò ´ µ Ø ÕÙ Ð ØÝ Ó Ø Ô Ø Ò Ø Î Æ Ì ÁÒ ×Ù
Ò ØÛÓÖ × Ú
Ð ¸ ÕÙ ÔÔ Û Ø Û Ö Ð ×× Ö ¹ Ø Ø Û Ýº ÁÒ Ø Ü ÑÔÐ Ó ÒØ Ö
¸ Ö
ØÐÝ ØÖ Ò×Ñ Ø× Ò ÓÖÑ Ø ÓÒ ØÓ ÓØ Ö Ú ¹ ÖÓÑ Ø Ù× Ö ØÓ Ø
Ò ÓÚ ¸ Ù× Ö Û ÐÐ Ò ØÓ Ò Ø Ø ÉÓË × Ò× Ø Ú × ×× ÓÒ ØÓ
Ð × Û Ø ÓÙØ Ø Ù× Ó Ø Ö ÔÖ Ú ÓÙ×ÐÝ ÔÐÓÝ Ò Ö ×¹ Ø Û Ý¸ Û Ò ØÖÙ
ØÙÖ ÓÖ
ÒØÖ Ð Þ
ÓÒØÖÓк ËÙ
ÒØ Ö¹Ú
ÙÐ Ö Ò Ø¹ Ò ÜØ ÖÒ Ð Ò ØÛÓÖ
ÓÙÐ ×
Ö Ø ËÈ »× × Û Ö Ø Ø Ø Ô Ø ØÓ Ø × Ø Û Ý Ø ÖÓÙ Ø ÛÓÖ ×¸ Ò Û
Ú
Ð × ÓÒ Ø ÖÓ × ÝÒ Ñ
ÐÐÝ ÓÖÑ
ÓÒ¹ Ø ÒÙÓÙ×ÐÝ
Ò Ò ØÓÔÓÐÓ ×¸ Ö Ó Ø Ò Ö ÖÖ ØÓ × Î ¹ Î Æ Ì × ÙÒ×Ø Ð ÓÖ
ÓÒ ×Ø º ÓÚ Ö ÔÓÖØ
ÓÒ× Ö Ø ÓÒ×
Ð ÖÐÝ Ò Ø
Ó
ÙÐ Ö ¹ Ó
Æ ØÛÓÖ × ´Î Æ Ìµº ËØÙ × Ú ÑÓÒ¹ Ó Ø Ö Ø Ø Û Ý × Ò Ò Ö ÒØÐÝ
ÖÓ××¹Ð Ý Ö ××Ù º ×ØÖ Ø Ø Ø ÑÓÚ Ò Ú
Ð × Ò Î Æ Ì
Ò ÜÔÐÓ Ø ¹ Ò Û Ø ¸ × ÓÖØ¹Ö Ò
ÓÑÑÙÒ
Ø ÓÒ Ø
ÒÓÐÓ ×¸ ×Ù
ÁÒ
ظ × ÖÚ
×Ù ×
Ö ÔØ ÓÒ Ò ÔÖ
Ò Ù×Ù ÐÐÝ Ô ÖØ Ò ØÓ Ù× Ö» ÔÔÐ
Ø ÓÒ Ð Ú Ð× × ØØ Ò ÙÔ ÉÓË ÔÔÐ
Ø ÓÒ ×Ø Á ¼¾º½½¹ × ×Ø Ò Ö × ½℄º Ï Ò Ò ÐÝ× Ò Ð ÐÝ ÔÔÐ
Ø ÓÒ× ÓÖ Ú
ÙÐ Ö Ò ØÛÓÖ ×¸ × ØÝÔ
Ð × ×× ÓÒ Ò Ø Ø ÓÒ ÔÖÓ Ð Ñ Ò Ò Ø ÖÓÙØ ØÓ Ø Û Ý × Ù×Ù ÐÐÝ
ÓÑÔÐ × Ø ÖÓÙ Ò ØÛÓÖ ¹ Ø ÑÓ×Ø Ö Ð Ú ÒØ
Ø ÓÖ × ÙÒ ÓÙ Ø ÐÝ Ö ×ÙÐØ ØÓ Ð Ý Ö ÔÖÓ
ÙÖ × Ò ¸ Ò ÐÐݸ
ÓÐÐ
Ø Ò Ò ÓÖÑ Ø ÓÒ ÓÙØ
ÓÑÔÙØ Ö¹ Ö Ú Ò Ò Ô ×× Ò Ö ÒØ ÖØ ÒÑ Òغ ÁÒ Ý Å ÙÑ
×× ÓÒØÖÓÐ ÓØ
× ×¸
ÓÑÑÓÒ Ö ÕÙ Ö Ñ ÒØ × Ø Ð ØÝ Ó Ø Ò Ø¹ Ø ×Ø Ø Ó Ð Ò × ÙÐ ÐÐ ´Å µ»È ×
Ð Ð Ý Ö ÙÒ
Ø ÓÒ׺ ÛÓÖ ØÓ Ó Ö
ÓÒ×Ø ÒØ
×× ØÓ Ø ÁÒØ ÖÒ Ø ØÓ Ø Ö Ö Ñ ÛÓÖ × ÓÒ
ÖÓ××¹ ÛØ
ÓÒØÖÓÐÐ ÉÙ Ð ØÝ Ó Ë ÖÚ
´ÉÓ˵ ØÓ Ø Ù× Ö׺ ÁÒ Ø × Ô Ô Ö¸ Û ÔÖÓÔÓ× Ð Ý Ö ÔÖ Ò
ÔР׸ Û
ÓÑ Ò × Ø ÙÒ
Ø ÓÒ Ð Ø × Ó Ì × Ð ØØ Ö Û ÐÐ Ð ÐÝ
Ö Ø
Ð
ØÓÖ× ØÓ Ø ×Ù
×× Ó Ú
ÙÐ Ö Ò ØÛÓÖ ×º ÍÒ ÓÖØÙÒ Ø Ðݸ Ò ×Ô Ø Ó Ø × ×ØÖÓÒ Ë ÈÒ ´Ë ×× ÓÒ ×
Ö ÔØ ÓÒ ÈÖÓØÓ
ÓÐ Æ ÜØ Ò Ö Ø ÓÒµ ¾℄¸ ÑÙÐØ Ñ ¹ Ö ÕÙ Ö Ñ ÒØ× Ò Ò ÁÒØ ÖÒ Ø
ÓÒÒ
Ø Ú ØÝ Ò Î Æ Ì × Ò Á Ì ÔÔÐ
Ø ÓÒ ÔÖÓØÓ
ÓÐ Ù× ØÓ ×
Ö × ×× ÓÒ׸ Û Ø ÔÓÔÙÐ Ö ÖÓÙØ Ò ÔÖÓØÓ
ÓÐ ÓÖ ÑÓ Ð Ú ÖÝ
ÐÐ Ò Ò Ó
Ø Ú Ø Ø Ö ÕÙ Ö × Ø ÔÖ × Ò
Ó Ó
Ò ØÛÓÖ ×¸ Ó
ÇÒ¹ Ñ Ò ×Ø Ò
Î
ØÓÖ ×Ù Ø Ð ÒÓ ×¸
ÐÐ Ø Û Ý׸ Û
ÔÖÓÚ
ÓÒÒ
Ø Ú ØÝ ´ Ç Îµ ¿℄¸ Ò Û Ø Ø Å ÔÖÓØÓ
ÓÐ Ó ¼¾º½½¹ × ØÓÛ Ö × ÜØ ÖÒ Ð Ò ØÛÓÖ ×º Ì Ý
Ò Ø Ö ×Ø Ø ÓÒ Öݸ º º ÔÐ
Ø Ü ÔÓ× Ø ÓÒ× ÐÓÒ Ø ÖÓ × ¸ ÓÖ ØÖ Ú Ð Ï Ö Ð ×× ÄÓ
Ð Ö Æ ØÛÓÖ × ´ÏÄ Æ×µº ÓÒ Ó Ö ×ÓÑ Ú
Ð × Ò
Ø × ÑÓ Ð Ø Û Ý׺ Ò ¹ ÁÁº
ÖÓÙÒ Ó
Ò ØÛÓÖ ÐÐÓÛ× Ú
Ð × Ò Î Æ Ì ØÓ
ÓÑÑÙÒ
Ø ØÓ ÓØ ÖÓ × Ò ÓÒ¹ Ó Ö ÁÒØ ÖÒ Ø Ø Û Ý׺ ÁØ × Ó ¹ Å ÒÝ ×Ô
Ø× Ó Ø Ø Û Ý × Ð
Ø ÓÒ¸ ×Ù
× Ø Û Ý Ú ÓÙ× ØÓ ×ÙÔÔÓ× Ø Ø Ø Ú
Ð × Ó ÒÓØ ÒÓÛ ÔÖ ÓÖ ×
ÓÚ ÖÝ Ò Ò ¹ØÓ¹ Ò ÉÓË × Ò Ð Ò ¸ Ú Ò Û ÐÝ Û
Ø Û Ý Û ÐÐ Ú Ð Ð ÒØ ÖÒ ÓÖ ÓÓ ¸ Ò Ö ×× Ò Ø ×
ÒØ
Ð Ø Ö ØÙÖ ¸ Ñ ÒÐÝ × Ò Ú Ù Ð Ø × Ð ÐÝ Ø Ø Ø × Ñ Ö
Ò
ÓÚ Ö Ý ÑÓÖ Ø Ò ØÓÔ
׺ ÓÓ Ö Ö Ò
ÓÖ Û Ø Û
ÐÐ Ò ØÛÓÖ ¹Ð Ú Ð ÓÒ Ø Û Ýº Ì Ö ÓÖ ¸ Ò ×Ù
×
Ò Ö Ó¸ Ø Ñ Ø Ó ÔÔÖÓ
´Û Ò Ø Û Ý ×
ÓÚ ÖÝ ×
ÓÒ× Ö × Ò Ü¹ ØÓ ×
ÓÚ Ö Ò × Ð
Ø Ø Ö Ø Ø Û Ý¸ Û
Ù× Ö׳ Ø Ò× ÓÒ Ó Ø ÖÓÙØ Ò ÔÖÓ
ÙÖ µ × ¿℄º Ì ÙØ ÓÖ× Ù ¹ ØÖ
× ØÓ Ð Ú Ö Ø ÖÓÙ ¸ ØÙÖÒ× ØÓ
ØÓÖ Ñ ÒØ Ç Î Û Ø Ø Û Ý ×
ÓÚ ÖÝ
Ô Ð Ø × ØÓ ÔÖÓÚ Ó ÙØÑÓ×Ø ÑÔÓÖØ Ò
º Ç Ú ÓÙ×Ðݸ Ø
Ó
Ó Ø Ö Ø ÁÒØ ÖÒ Ø
ÓÒÒ
Ø Ú ØÝ ØÓ ÒÓ × Ò ÑÓ Ð Ó
Ò ØÛÓÖ º
UbiCC Journal – Volume 3
16
¾
Ì
ÜØ Ò Ú Ö× ÓÒ Ó Ø ÔÖÓØÓ
Óи Ò Ñ Ç Î·¸ Ù× × Ò Û
ÓÒØÖÓÐ Ñ ×× ¸
ÐÐ ÊÊ È Á¸ Û
× × ÒØ
Ý Ø Ø Û Ý Ø Ö Ö
ÚÒ ÖÓÙØ Ö ÕÙ ×Ø ´ÊÊ Éµ Ñ ×× ÓÖ Ò ÒØ Ò ×Ø Ò Ø ÓÒ ÐÓ
Ø ÓÙØ× Ø ¹ Ó
Ò ØÛÓÖ º Ì ×ÓÙÖ
ÒÓ Ù× × Ø ÊÊ È Á Ñ ×× ØÓ × Ð
Ø ÓÒ Ó Ø Ö ×ÔÓÒ Ò Ø Û Ý׸ º º Ø Ò Ö ×Ø ÓÒ º Ì ÙØ ÓÖ× Ó ℄ ÔÖÓÔÓ× Ò ÜØ Ò× ÓÒ Ó ¿℄ Û
Ø × ÒØÓ
ÓÙÒØ Ø Ð ¹Ø Ñ Ó Ø Ô Ø × ØÓ Ø
Ò ¹ Ø Ø Û Ý× ØÓ
ÓÓ× Ø ×Ø ÓÒ ØÓ
×× Ø ÁÒØ ÖÒ Øº Ì Ð ¹Ø Ñ Ó Ð Ò × ÔÖ
Ø Ý ×ÙÔÔÓ× Ò Ø Ø
Ú
Ð ÒÓÛ× Ø× ÓÛÒ ÔÓ× Ø ÓÒ¸ ×Ô Ò Ö
Ø ÓÒ Ò Ø Ó× Ó ÐÐ Ø×
ÓÖÖ ×ÔÓÒ Ò ÒÓ ×¸ Ò Ý ××ÙÑ Ò Ö ×Ô
ÔÖÓÔ Ø ÓÒ ÑÓ Ð Ú ÐÙ Ø ÓÒÐÝ ÓÒ
¸ ÙÖ Ò Ø ÖÓÙØ ×
ÓÚ ÖÝ Ô × º È Ø Ð ¹Ø Ñ × ÙØ Ð Þ ØÓ ´ µ × Ð
ظ ÑÓÒ Ú Ð Ð Ô Ø ×¸ Ø ÓÒ Û Ø Ø ÐÓÒ ×Ø Ð ¹Ø Ñ ¸ ´ µ Ò ØÓ ØÖ Ö Ò Û ÖÓÙØ ×
ÓÚ ÖÝ ÔÖÓ
ÙÖ ÓÖ Ø ÓÐ ÓÒ
ØÙ ÐÐÝ
Ö × ×º Ì Ó Ø Ò Ô Ö ÓÖÑ Ò
× ØØ Ö Ø Ò Ø ÓÒ Ó Ø Ò Ø ÖÓÙ Ø ×
ÔÖÓØÓ
ÓÐ ÔÖ × ÒØ Ò ¿℄º ÀÓÛ Ú Ö¸ Ø ×Ø ÐÐ ×Ù Ö× ÖÓÑ ×ÓÑ Ò ¹
Ò
× Ñ ÒÐÝ Ö Ð Ø ØÓ Ø × ÑÔÐ Û Ý Ô Ø ¹Ð Ø Ñ ×
ÓÑÔÙØ Ò ØÓ Ø
Ó
Ó ×Ø Ñ Ø Ò Ø Ô Ø ¹Ð Ø Ñ ÓÒÐÝ ÓÒ
¸ ÙÖ Ò Ø ÖÓÙØ × Ø¹ÙÔ Ô × º × Ò Ð ×Ø ¹ Ñ Ø ÓÒ¸ Ò
ظ Ó × ÒÓØ ÐÐÓÛ ØÓ Ø ÒØÓ
ÓÙÒØ Ø Ö ÕÙ ÒØ ØÓÔÓÐÓ Ý
Ò × Ó
ÙÖÖ Ò Ò Î Æ Ìº Ì Ô¹ ÔÖÓ
Û ÒØÖÓ Ù
Ò Ø ÔÖ × ÒØ Ô Ô Ö × × ÓÒ
ÓÒ×Ø ÒØ ÑÓÒ ØÓÖ Ò Ó Ø
ÒÒ Ð ÕÙ Ð ØÝ Ø Ù׸ Ø × Ü¹ Ô
Ø Ø Ø Û Ò ×× × Ð Ø Ò ℄
Ò ÓÚ Ö
ÓÑ º × ÓÖ Ø ÉÓË Ñ Ò Ñ ÒØ ××Ù ¸ Ö Ö Ò
℄ ÔÖÓÚ × Ñ
Ò ×Ñ ÓÖ Ò ¹ØÓ¹ Ò ÉÓË ÔÖÓÚ × ÓÒ Ò Ò
ÓÑÔÐ Ü Ø ÖÓ Ò ÓÙ× Ò ØÛÓÖ × Ø ÖÓÙ ÔÓÐ
ݹ × Ñ Ò ¹ Ñ ÒØ Ó Ø ÁÈ
ÓÒ º Í× Ö× Ò Û Ö
×× Ò ØÛÓÖ Ö
ÓÒÒ
Ø ØÓ Ø
ÓÒ Ú ×Ô
Ð Ø Û Ý Ú
Ø Ò × ÓØ ÈÓÐ
Ý Ò ÓÖ
Ñ ÒØ ÈÓ ÒØ ´È ȵ ℄ Ò Ë ×× ÓÒ ÁÒ Ø Ø ÓÒ ÈÖÓØÓ
ÓÐ ´ËÁȵ ℄ ÔÖÓÜݺ
Ø Ñ Ù× Ö Û ÒØ× ØÓ ×Ø ÖØ ÉÓË × ×× ÓÒ¸ »× ××Ù × ËÁÈ Áƹ ÎÁÌ Ñ ×× ØÓ Ø Ø Û Ýº Ì × Ð ØØ Ö ØÖ Ò×Ð Ø × ËÁÈ Ô Ö Ñ Ø Ö× ÒØÓ ÉÓË Ö ÕÙ Ö Ñ ÒØ× Ò ×Ø ÖØ× ÔÓÐ
Ý Ò ¹ ÓØ Ø ÓÒ ÔÖÓ
×× Û Ø Ø ÈÓÐ
Ý
× ÓÒ ÈÓ ÒØ ´È ȵ ℄º Á ÒÓÙ Ö ×ÓÙÖ
× Ö Ú Ð Ð Ò Ø ÁÈ
ÓÒ Ò Ø Ù× Ö × ×Ù
ÒØ ÔÖ Ú Ð ×¸ Ø Ò Ø ÔÓÐ
Ý Ò ÓØ ¹ Ø ÓÒ ×Ù
× Ò Ø Ø Û Ý ÓÖÛ Ö × Ø ËÁÈ ÁÆÎÁÌ Ñ ×× ÓØ ÖÛ × Ø × ×× ÓÒ Ò ×º Ð Ñ Ø Ó ËÁȹ × ÉÓË Ð × Ò Ø× Ö ×ØÖ
Ø Ô Ö Ñ Ø Ö × Ø¸
ÓÒ× ×Ø Ò Ó
Ó
× Ò Ö ÕÙ ×Ø Ø¹Ö Ø ×º Ì × × Ø Ó × ÒÓØ ÐÐÓÛ Ø Ù× Ö ØÓ ÜÔÖ ×× ÑÓÖ
ÓÑÔÐ Ü ÜÔ
Ø Ø ÓÒ× ÓÙØ Ø ÉÓË Ð Ú Ð× ÓÖ Ø Ö ÕÙ ×Ø × ÖÚ
׺ ÁÒ Ø × Ô Ô Ö¸ Û ×ÓÑ ÓÛ ÜÔÐÓ Ø ÓØ ÔÔÖÓ
× Ò ¿℄ Ò ℄ ØÓ Ø Ö Û Ø Ø ÖÓÙ ÔÙØ Ò Ð Ý ×Ø Ñ Ø ÓÒ ÔÖ × ÒØ Ò ℄ Ý ÔÖÓÔÓ× Ò
ÖÓ××¹Ð Ý Ö Ö Ñ ÛÓÖ ØÓ ÐÐÓÛ ÑÓ¹ Ð Ó×Ø Ò Ø Î Æ Ì × Ð
Ø Ò Ø ×Ø Ø Û Ý ØÓ Ø ÜØ ÖÒ Ð Ò ØÛÓÖ º Ë Ð
Ø ÓÒ Ø × ÒØÓ
ÓÙÒظ Ø Ø × Ñ Ø Ñ ¸ ÓØ ÐÓÛ¹Ð Ú Ð Ô Ö Ñ Ø Ö× ´×Ù
׸ × Ö Ø ÖÓÙ ¹ ÔÙØ Ò Ð Ýµ ÑÓÒ ØÓÖ Ý Ø ÖÓÙØ Ò ¹Å Ð Ý Ö× Ò Ö Ð Ú Ð ÓÒ × ´×Ù
×
Ó×ظ × ÖÚ
Ð Ú Ð Ö Ñ ÒØ׸ ÓÔ Ö ØÓÖµ¸
ÓÒØÖÓÐÐ ØØ ÔÔÐ
Ø ÓÒ Ð Ý Öº
º ½º
Æ ØÛÓÖ
×
Ò Ö Ó
Ò
Ë
Ò Ð Ò
ÓÛ×
ÁÁÁº Ì
ÔÖÓÔÓ×
×Ø
ÖÓ××¹Ð Ý Ö Ö Ñ ÛÓÖ Ø Û Ý Ë Ð
Ø ÓÒ
ÓÖ
ÁÒ Ø × ×
Ø ÓÒ Û ×ÙÑÑ Ö Þ Ø Ö Ö Ò
×
Ò Ö Ó ´× Ø
Ò º ½µ¸ Ø Ñ Ò ÔÖÓ
ÙÖ ×¸ Ò Ø ÒÓÚ Ð ØÙÖ × Ó ÓÙÖ ÔÔÖÓ
º Ë Ò
ÓÙÖ Ñ Ò Ó
Ù× × ÓÒ ÉÓË ÔÖÓÚ × ÓÒ Ò ØÓ ÑÙÐØ Ñ × ÖÚ
׸ Û ×ÙÔÔÓ× Ø Ø ÑÓ¹ Ð ÒÓ × ×ÙÔÔÓÖØ ËÁÈ ÔÖÓØÓ
ÓÐ Ò Ù× Ø ØÓ ×Ø ÖØ Ø Ö ÑÙÐØ Ñ × ×× ÓÒ׺ Ä Ò ℄¸ Û Ð×Ó ××ÙÑ Ø Ø Ø × ÔÓ×× Ð ØÓ Ø Ö Ò
Ø ÓÒ× ÓÒ Ø ÉÓË Ð Ú Ð× Ö ÕÙ Ö Ý Ø Ù× Ö× ÖÓÑ × ×× ÓÒ ×
Ö ÔØ ÓÒ Ô Ö Ñ Ø Ö׺ ËÁÈ ÜÔÖ ×¹ × Ú Ò ×× × Ù Ñ ÒØ Ò ÓÙÖ ÔÖÓÔÓ× Ð Ý Ù× Ò Ò Ò Ò
× ×× ÓÒ ×
Ö ÔØÓÖ ÔÖÓØÓ
Óи Ò Ñ ÐÝ Ë ÈÒ ¾℄º ÁÒ ÓÙÖ Ö Ö Ò
×
Ò Ö Ó¸ Ø Û Ý× Ú × ËÁÈ ÔÖÓܹ ׸ Ð ØÓ
Ù× Ö׳ Ë ÖÚ
Ä Ú Ð Ö Ñ ÒØ× ´ËÄ ×µ Ò ØÓ ×× ×× Ø Ò ØÛÓÖ Ö ×ÓÙÖ
× Ø Ø
Ò ×× Ò ØÓ Ø Ñº ÓÖ Ò×Ø Ò
¸ Ò ÔÓÐ
ݹ ×
ÓÖ Ò ØÛÓÖ ¸ Ø ¹ Û Ý×
Ò ÑÔÐ Ñ ÒØ ÈÓÐ
Ý Ò ÓÖ
Ñ ÒØ ÈÓ ÒØ× ´È È×µ Ò Ù× ÇÈË ÔÖÓØÓ
ÓÐ ØÓ ÒØ Ö
Ø Û Ø ÈÓÐ
Ý
× ÓÒ ÈÓ ÒØ× ´È È×µ¸ Û
Ò ØÙÖÒ Ñ Ò Ø
ÓÖ Ò ØÛÓÖ Ø Ý ÐÓÒ ØÓ ℄º ÉÓË Ñ Ò Ñ ÒØ Ø
Ò ÕÙ × Ù×
ÖÓ×× Ø
ÓÒ Ò ØÛÓÖ ÐÐ ÓÙØ Ó Ø ×
ÓÔ Ó Ø × Ô Ô Ö¸ Ø Ó
Ù× Ò ÓÒ Ø
×× Ò ØÛÓÖ º
º Ø Û Ý Ë Ð
Ø ÓÒ
Ì × Ô × Ö ÕÙ Ö ×
ÓÓÔ Ö Ø ÓÒ ØÛ Ò ÔÔÐ
Ø ÓÒ ´Ë ÈÒ µ Ò Ò ØÛÓÖ ´ Ç Îµ Ð Ý Ö׺ Ï Ò Ù× Ö Û ÒØ× ØÓ ×Ø ÖØ ÑÙÐØ Ñ × ×× ÓÒ ´× º ½µ »×
Ð Ö × ´½µ Ù× Ö Ò ÔÔÐ
Ø ÓÒ Ö ÕÙ Ö Ñ ÒØ× Û Ø Ò Ø ËÁÈ ÁÆÎÁÌ Ñ ×× ¸ Ý Ù× Ò Ë ÈÒ ¾℄ × ×× ÓÒ ×
Ö ÔØ ÓÒ ÔÖÓØÓ
Óк Ï ÔÖÓÔÓ× Ø ËÁÈ ÁÆÎÁÌ Ñ ×× ØÓ Ñ ÒØÓ Ø Ô ÝÐÓ Ó ÖÓÙØ Ò ×
ÓÚ ÖÝ Ô
Ø× ´ÊÊ Éµº Ø Û Ý× ÑÙ×Ø ×× ×× Ø Ð ØÝ Ó Ø ÜØ ÖÒ Ð Ò ØÛÓÖ ×¸ ÐÓÒ Ø Ô Ø ØÓ ×Ø Ò Ø ÓÒ¸ ØÓ Ñ Ø
Ù× Ö Ò ¹ØÓ¹ Ò ÉÓË Ö ÕÙ Ö Ñ ÒØ׺ ÌÓ Ø × Ñ¸ Ø Ý Ð×Ó Ù× Ò ÓÖÑ Ø ÓÒ¸
ÓÑ Ò ÖÓÑ Å Ò È Ý×
Ð Ð Ý Ö׸ ÓÙØ Ø
Ú¹ Ð ÉÓË Ð Ú Ð× Û Ø Ò Ø Î Æ Ì × Ñ Òظ
ÓÐÐ
Ø Û Ð ÖÓÙØ Ò Ö ÕÙ ×Ø×
ÖÓ×× Ø Î Æ Ìº È Ö Ñ Ø Ö× Ø Ò ÒØÓ
ÓÙÒØ Ö Ñ Ü ÑÙÑ
Ú Ð Ø ÖÓÙ ÔÙظ Ñ Ò ÑÙÑ Ð Ý¸ Ò ×Ø Ñ Ø Ô Ø Ð ¹Ø Ñ º Ø Û Ý×
ÓÑÔ Ö ´¾µ Ø Ù× Ö³× Ö ÕÙ Ö Ñ ÒØ× Û Ø Ø Ö ÓÛÒ
Ô Ð Ø × Ò Û Ø Ø Ó× Ó Ø ÜØ ÖÒ Ð Ò ØÛÓÖ × Ø Ý Ö
ÓÒÒ
Ø ØÓº ÇÒÐÝ Ø Û Ý× Û
Ö Ð ØÓ Ó Ö Ø Ö ÕÙ Ö ÉÓË Ð Ú Ð× Ò ÔÔÐ
Ø ÓÒ ØÙÖ × Ö ×ÔÓÒ ´¿µ Û Ø ÖÓÙØ Ö ¹ ÔÐÝ Ñ ×× º Ì Ù× Ö
ÓÓ× × Ø Û Ý¸ ÑÓÒ Ø Ó×
UbiCC Journal – Volume 3
17
¿
ÐØ × ´µ Ø × Ø × Ñ Ø Û Ý Û
Û × ÐÖ Ý ÓÖ¹ Û Ö Ò Ø Ù× Ö ØÖ
´Ø ÖÓÙØ Ò Ø ¹ Ó
× Ò ÖÔ Ö Ò Ø Ø Û Ý × ÙÒ
Ò µ¸ ÓÖ ´ µ Ø × Ò Û Ø Û Ýº ÁÒ Ø ÓÖÑ Ö
× ¸ Ø
ÓÒØ ÒÙ × ØÓ Ó Ø× Ó × ÓÖ Ò Ø Ð ØØ Ö
× ¸ Ø ÓÖÛ Ö × ´ µ Ø Ö ¹ ÒÚ Ø Ñ ×¹ × ØÓ Ø Ö ÑÓØ ×Ø Ò Ø ÓÒ¸ Ò Ø
ÓÑÑÙÒ
Ø ÓÒ ÓÛ
Ò
ÓÒØ ÒÙ ØÛ Ò × Ò Ö Ò Ö
Ú Ö Ø ÖÓÙ Ø Ò Û Ø Û Ý ´ µº × ×ÓÓÒ × Ø Ù× Ö Ö
Ú × Ø ÖÓÑ Ø Ò Û Ø Û Ý¸ Ø × Ò × Ý Ñ ×× ØÓ Ö × ÐÐ ÖÓÙØ Ò ÒØÖ × Ð Ð × ÜÔ Ö Ò ´½¼µº
Áκ ×Ø Ñ Ø Ò Ø È Ø ¹Ä Ø Ñ
ÒÓ ×
ÓÒØ ÒÙÓÙ×ÐÝ Ú ÐÙ Ø × Ø ÊËËÁ Ó
Ð Ò
ÓÒÒ
Ø Ò ØÓ Ø× Ò ÓÖ׺ Ì × Ú ÐÙ × ÖÓÑ È Ý×
Ð Ð Ý Ö Ö ÔÖÓ
×× Ý Ø ÖÓÙØ Ò ÔÖÓØÓ
ÓÐ Ø Ø Æ ØÛÓÖ Ð Ý Öº
Ø Ñ ÒÓ Ö
Ú × Ö Ñ ¸ Ø Ñ ×ÙÖ × Ø Ö
Ú ÊËËÁ Ò
ÓÑÔÙØ × Ø Ú Ö Ø ÓÒ Û Ø Ö ×Ô
Ø ØÓ Ø ÓÖ¹ Ñ Ö Ñ ×ÙÖ ¸
ÓÖ Ò Ø ÓÐÐÓÛ Ò ÕÙ Ø ÓÒ
∆RSSI(tactual ) = RSSI(tactual ) − RSSI(tf ormer ) (tactual − tf ormer )
º ¾º
Ë
Ò Ð Ò
ÐÓÛ
ÙÖ Ò
À Ò ÓÚ Ö
Û
Ö ÔÐ ØÓ Ø ÖÓÙØ Ö ÕÙ ×Ø Ñ ×× ¸ º º Ø ÓÒ Û Ø Ø ÐÓÒ ×Ø Ô Ø Ð ¹Ø Ñ ¸ Ò ××Ù × ´ µ
ÓÒ ÖÑ ¹ Ø ÓÒ Ñ ×× ØÓ Ø Ø Ø Û Ýº Ò ÐÐݸ ÙÔÓÒ Ö
Ú Ò Ø
ÓÒ ÖÑ Ø ÓÒ Ñ ×× ¸ Ø Ø Û Ý ÓÖÛ Ö × ´ µ ØÓ Ø Ò Ð ×Ø Ò Ø ÓÒ Ø ËÁÈ ÁÆÎÁÌ Ñ ×× Ö
Ú ÙÖ Ò ×Ø Ô ¾º
º ÊÓÙØ ØÓ Ø Ø Û Ý Å ÒØ Ò Ò
´½µ
Ì × Ô × Ö ÕÙ Ö × Ø Ò ØÛÓÖ Ð Ý Ö ´ Ç Îµ ØÓ Ö
Ú Ú ÐÙ × Ó ÑÓÒ ØÓÖ Ô Ö Ñ Ø Ö× Ø Ø È Ý×
Ð Ð Ý Öº Ý Ö ÖÖ Ò ØÓ º ¾¸ Û Ò Ô Ø × × Ø ÙÔ ´½µ ÐÐ Ø ÒÓ ×
ÓÒØ ÒÙÓÙ×ÐÝ ÑÓÒ ØÓÖ Ø ÊËËÁ ´Ê
Ú Ë Ò Ð ËØÖ Ò Ø ÁÒ
Ø ÓÒµ ÖÓÑ Ø Ö Ò ÓÖ׺ Ï Ò ÓÒ Ó Ø Ñ Ö Ð¹ Þ × ´¾µ Ø Ø Ø Ð Ò × Ö Ô ÐÝ Ø Ö ÓÖ Ø Ò ´ÔÐ × Ö Ö ØÓ ×
Ø ÓÒ ÁÎ ÓÖ Ø Ð×µ¸ Ø Ò Ø Ð Ð× Ø ÖÓÙØ × ÜÔ Ö Ò Ò
Ö Ø
Ð º Ì Ð Ð ÜÔ Ö Ò Ñ Ò× Ø Ø ÖÓÙØ × Ó Ò ØÓ ÙÔ Ø ¸ Û Ð Ø Ð Ð
Ö Ø
Ð Ñ Ò× Ø Ø Ø Ð Ò ØÓ Ø Ò ÜØ ÓÔ × Ö Ô ÐÝ Ó Ò ØÓ Ö º ÇÒ
Ø Ó×Ø × Ð Ð Ø× ÖÓÙØ Ò Ø Ð ¸ Ø ××Ù × ´¿µ ÊÓÙØ ¹ Ð ÖØ Å ×× ÙÔ×ØÖ Ñ ØÓ Ø Ë Ò Öº
ÒÓ Ò Ø ÖÓÙØ ÑÓ × Ø× ÖÓÙØ Ò Ø Ð ÒØÖݸ Ý Ð Ð Ò Ø ÖÓÙØ × ÜÔ Ö Ò ¸ Ò Ô× ÓÒ ÓÖÛ Ö Ò Ø Ð ÖÑ Ñ ×× ÙÔ×ØÖ Ñ ØÓ Ø Ë Ò Öº ÀÓÛ Ú Ö¸ ÐÐ Ø ÒÓ ×
ÓÒØ ÒÙ ØÓ Ù× Ø Ü ×Ø Ò ÖÓÙØ ØÓ ÓÖÛ Ö Ø Ø Ô
Ø׺ Ì ×ÓÙÖ
¸ ÙÔÓÒ Ø Ö
ÔØ ÓÒ Ó Ø ÊÓÙØ ¹ Ð ÖØ Å ×× ¸ ×× Ñ Ð × ´ µ ËÁÈ Ö ¹ ÒÚ Ø Ñ ×× Ò
ÐÙ Ò Ø ¹ ×
Ö ÔØ ÓÒ Ó Ø× Ö ÕÙ Ö Ñ ÒØ× Ý Ù× Ò Ë ÈÒ ¾℄¸ × Û Û ÐÐ ×
Ö Ð Ø Öº Ì Ö ¹ ÒÚ Ø Ñ ×× × Ñ ÒØÓ ÊÓÙØ ¹ÍÔ Ø Å ×× º ÇÒ
Ò¸ Û Ú
ÖÓ××¹Ð Ý Ö
ÓÓÔ Ö Ø ÓÒ ØÛ Ò ÔÔÐ
Ø ÓÒ Ò Ò ØÛÓÖ Ð Ý Ö׺ Ï Ò Ó×Ø Ö
Ú × Ø ÊÓÙØ ¹ÍÔ Ø Å ×× ¸ Ø Ô Ö¹ ÓÖÑ× Ø × Ñ ÓÔ Ö Ø ÓÒ× × Ò
× Ó ÊÓÙØ ¹Ê ÕÙ ×Ø Å ×× ¸ÛØ Ø Ü
ÔØ ÓÒ Ø Ø Ø ÚÓ × ØÓ Ö Ù×
ÖÓÙØ × ØÓ Ø ×Ø Ò Ø ÓÒ Ö Ø Ö Ø Ô Ö ÓÖÑ× Ò Üع ÓÔ ×¹
ÓÚ Öݺ Ï ×ÙÔÔÓ× ÖÓÙØ Ñ Ý ÓÚ ÖÐ Ô Û Ø ÒÓØ Ö ÓÒ ÐÖ Ý Ü ×Ø Ò ¸ ÙØ Û Ó ÒÓØ ÐÐÓÛ Ø ØÓ Ò
ÐÙ Ð Ò × Ð Ð ×
Ö Ø
Ð º ØØ Ò Ó Ø ×
ÓÚ ÖÝ Ô × ¸ ÐÐ Ø Ø Û Ý× Ð ØÓ Ò Ð Ø Ù× Ö ØÖ
Ö ×ÔÓÒ ´ ¹ µ Û Ø ÊÓÙØ ¹Ê ÔÐÝ Å ×× º Ë Ñ Ð ÖÐÝ ØÓ Ø × Ø¹ÙÔ
× ¸ Ø Ù× Ö
ÓÓ× × Ø Û Ý¸ ÑÓÒ Ø Ó× Û
Ö ÔÐ ØÓ Ø ÊÓÙØ ¹ÍÔ Ø Å ×× ¸ Ò × Ò × ´ µ ØÓ Ø ÓÒ ÖÑ Å ×× º Ï Ò ÖÓÙØ Ö Ö
Ú × ÓÒ ÖÑ Å ×× Ø Ö Ö ØÛÓ ÔÓ×× ¹
Û Ö tactual Ò tf ormer Ö ÔÖ × ÒØ× Ø Ø Ñ Ò×Ø ÒØ× Ó Ø
ÙÖÖ ÒØ Ñ ×ÙÖ Ò Ø ÓÖÑ Ö Ñ ×ÙÖ ¸ Ö ×Ô
Ø Ú Ðݺ ÌÓ ÐØ Ö ÓÙØ Ù
ØÙ Ø ÓÒ× Ò ÕÙ Ø ÓÒ ´½µ¸ Û
ÓÒ× Ö Ò ÚÖ Ñ ×ÙÖ ∆RSSI(tactual )¸ Û
× Ó Ø Ò ÖÓÑ ∆RSSI(tactual ) Ø ÖÓÙ Ò ÜÔÓÒ ÒØ Ð Ï Ø ÅÓÚ Ò ÚÖ ´ ÏÅ µ Û Ø ×Ù Ø ÐÝ
Ó× Ò ×ÑÓÓØ Ò
¹ ØÓÖ αRSSI º Á ∆RSSI(tactual ) × Ö Ø Ö Ø Ò¸ ÓÖ ÕÙ Ð ØÓ¸ Þ ÖÓ¸ Ø Ô Ø × ××ÙÑ ØÓ ÒÓØ Ò
Ö Ø
Ð Ô × ¸ Ò Ô Ø ¹ Ð Ø Ñ × × Ø ØÓ Ò Ò ØÝ ÓØ ÖÛ × ¸ Ø × ×ÙÔÔÓ× Ø Ø RSSI Û ÐÐ
Ö × Ò Ø Ò ÜØ ÙØÙÖ Û Ø
ÓÒ×Ø ÒØ ØÖ Ò º Ì Ö ÓÖ ¸ Ø Ô Ø ¹Ð Ø Ñ ´pltµ × Ö Ð Ø ØÓ RSSItactual Ò ØÓ Ø Ö
Ú Ö × Ò× Ø Ú ØÝ ´S µ´ º º Ø ÊËËÁ Ú ÐÙ ¸ ÐÓÛ Û
Ø Ö
Ú Ö × ÒÓØ Ð ØÓ ÛÓÖ ÔÖÓÔ¹ ÖÐݵ Ø ÖÓÙ Ø ÓÐÐÓÛ Ò ÕÙ Ø ÓÒ
[RSSI(tactual ) − S] + ∆RSSI(tactual ) · plt ≥ 0 → (S−RSSItactual ) plt ≤
∆RSSI(tactual )
´¾µ
ÒÓ ¸ ÙÖ Ò Ø Ø Ü
Ò Ô × ¸
ÓÒØ ÒÙÓÙ×ÐÝ ×Ø Ñ Ø × Ø Ô Ø ¹Ð Ø Ñ º Á Ø ×Ø Ñ Ø plt
ÓÑ × × ÓÖØ Ö Ø Ò Ú Ò Ø Ñ ÒØ ÖÚ Ð HO− time¸ Ø ÒÓ ØÖ ¹ Ö× ÊÓÙØ ÙÔ Ø ÔÖÓ
ÙÖ ¸ × ×
Ö Ò ×
Ø ÓÒ ÁÁÁº Ì Ø Ñ HO− time ×
Ó× Ò ØÓ Ñ Ò Ñ Þ ÙÒÒ
×¹ × ÖÝ ÊÓÙØ ÙÔ Ø ÔÖÓ
ÙÖ × Ò ¸ Ø Ø × Ñ Ø Ñ ¸ ØÓ Ñ Ü Ñ Þ Ø ÔÖÓ Ð ØÝ Ø Ø¸ Û Ò ØÖ Ö ¸ Ø Ý Ö
ÓÑÔÐ Ø ÓÖ Ø ÓÐ ÖÓÙØ Ò Ø Ú ÐÝ Ö ×º ¹ Ø Ö Ø ÓÖÓÙ × ÑÙÐ Ø ÓÒ
ÑÔ Ò Û Ú
Ó× Ò ØÓ × Ø HO− time = 1.5secº
κ Å Ä Ú Ð ÉÓË ÅÓÒ ØÓÖ Ò ÁÒ ÓÙÖ Ö Ö Ò
Ö Ñ ÛÓÖ ÉÓË ÖÓÙØ Ò
Ó
× Ø Ø Ò ØÛÓÖ Ð Ý Ö Ö
ÓÑÔÐ × Ø ÖÓÙ
ÓÓÔ Ö Ø ÓÒ Û Ø Ø Å Ð Ý Öº ÉÓË
ÓÒØÖÓÐ Ø Ø Å Ð ÝÖ ×
Ú Ø ÖÓÙ Ø Á ¼¾º½½ ×Ø Ò Ö ℄º ÅÓÖ ×Ô
ÐÐݸ
UbiCC Journal – Volume 3
18
ÉÓË × Ñ Ò ¸ Ø ÖÓÙ Ø Ò Ò
×ØÖ ÙØ Ò¹ Ò Ð
×× ´ µ¸ Ý ÔÔÐÝ Ò ØÖ
ÔÖ ÓÖ Ø Þ Ø ÓÒ ØÓ Å Ö Ñ × Ó ÓÙÖ Ö ÒØ
Ð ×× ×¸ × ÓÒ ØÖ
Ö ¹ ÕÙ Ö Ñ ÒØ׺ Ð Ý × Ò× Ø Ú ÚÓ
ØÖ
× Ò Ð ØØ ×Ø ÔÖ ÓÖ ØÝ Ú Ó ØÖ
Ø× Ø ×Ù × ÕÙ ÒØ ÔÖ ÓÖ¹ ØÝ Ð Ú Ð Ò ÐÐݸ ÓÛ× Ñ Ö × ×Ø ÓÖØ Ò
¹ ÖÓÙÒ Ö Ñ Ò Ý
Ö × Ò
Ð ×× × Ó ÔÖ ÓÖ Øݺ Ô
Ø
ÓÑ Ò ÖÓÑ Ø Ò ØÛÓÖ Ð Ý Ö × Ö×Ø ÕÙ Ù Ø Ø ÄÓ
Ð Ä Ò ÓÒØÖÓÐ ´ÄÄ µ Ð Ý Ö ÙÒØ Ð Ø × ØÖ Ò×¹ Ñ ØØ ÝØ Å ÔÖÓØÓ
Óк Ì Ø Ñ Ö ÕÙ Ö ÝØ × Ð ØØ Ö ØÓ ØÖ Ò×Ñ Ø Ô
Ø ´DMAC,i µ Ô Ò × ÓÒ Ñ ÒÝ
ØÓÖ׸ ×Ù
× Ø Ô Ý×
Ð ØÖ Ò×Ñ ×× ÓÒ Ö Ø ´ ÝÒ Ñ¹
ÐÐÝ ÔØ Ý Ø ×Ø Ø ÓÒµ¸ Ö Ò ÓÑ
¹Ó ÒØ Ö¹ ÚÐ ÓÖ ØÖ Ò×Ñ ×× ÓÒ¸ Ø ÔÓ×× Ð Ö ØÖ Ò×Ñ ×× ÓÒ× Ù ØÓ
ÓÐÐ × ÓÒ× Û Ø ÓØ Ö Ö Ñ ×¸ Ò Ø× ÔÖ ÓÖ ØÝ iº DMAC,i × Ö Ð Ø ØÓ Ø Ñ Ü ÑÙÑ Ø ÖÓÙ ÔÙØ ´M axT hi µ
Ú Ð Ý ×Ø Ø ÓÒ Ø Ø ÔÖ ÓÖ ØÝ i Ø ÖÓÙ M axT hi = P ktSize , i = 0, . . . , 3¸ Û Ö P ktSize × Ø DM AC,i Ô
Ø Ð Ò Ø ℄º Ì Ù׸ Ø ØÓØ Ð Ø Ñ ×Ô ÒØ Ý Ô
Ø Ò Ø Ø Ð Ò Ð Ý Ö ´ Äĵ ´DDLL,i µ¸
ÓÒ× ×Ø Ò Ó ÓØ ÄÄ Ò Å Ð Ý Ö׸ × Ú Ò Ý Ø ×ÙÑ Ó DMAC,i Ò Ø Ø Ñ ×Ô ÒØ Ò Ø ÕÙ Ù º ÁÒ ÓÙÖ Ö Ñ ÛÓÖ ¸ ×Ø Ø ÓÒ Ñ ¹ ×ÙÖ × ÓØ DDLL,i Ò DMAC,i ÓÖ
× ÒØ Ô
Ø Ò Ú Ö × Ø Ñ Ø ÖÓÙ Ò ÜÔÓÒ ÒØ Ð Ï Ø ÅÓÚ Ò ×ÑÓÓØ Ò
ØÓÖ × Ø ÚÖ ´EW M Aµ Ø
Ò ÕÙ Û Ø ØÓ 0.4
ÓÖ Ò ØÓ ℄º ÓÖ
×Ø Ø ÓÒ¸ ÉÓË ÖÓÙØ Ò Ö ¹ Ð × ÓÒ ×Ù
ÖÓ××¹Ð Ý Ö
ÓÓÔ Ö Ø ÓÒ Û Ø Å Ò ÄÄ Ð Ý Ö× ØÓ ×Ø Ñ Ø
Ú Ð Ð Ý× Ò Ø ÖÓÙ ÔÙغ ÅÓÖ Ø Ð× ÓÒ Ø × ××Ù Ö Ú Ð Ð Ò ℄º
Ø ÓÒ Îµ¸ Ò × Ø× ExpLif etime = min(ExpLif eT ime, plt) ´× ×
Ø ÓÒ Áεº ÓÖ ÓÖÛ Ö Ò ÊÊ É Ô
ظ Ò Ù×Ø Ø Ö Ø ÙÔ¹ Ø Ò ÔÖÓ
×× × Ò
ÓÑÔÐ Ø ¸
ÒÓ
× Ø Ø
M inT h ≥ P ktSize DM AC,i M axe2eDelay ≥ 0
´¿µ
ÇÒÐÝ ÓØ Ø
ÓÒ Ø ÓÒ× ÜÔÖ ×× Ò ´¿µ Ö ØÖÙ ¸ Ø Ò Ø ÊÊ É Ñ ×× × ÓÖÛ Ö ¸ ÓØ ÖÛ × Ø Û ÐÐ ×¹
Ö ºÏ Ò Ø Û Ý ´Û
Ø× × ËÁÈ ÔÖÓÜÝ × ÖÚ Öµ Ö
Ú × Ø ÊÊ É Ñ ×× ¸ Ø
Ò Ú
Ð Ö ×
Ö ÔØ ÓÒ Ó ÓØ Ø Ù× Ö» ÔÔÐ
Ø ÓÒ Ö ÕÙ Ö Ñ ÒØ׸
ÓÒØ Ò Ò Ø Ò
Ô×ÙÐ Ø ËÁÈ Ñ ×× ¸ Ò Ø ÉÓË Ö Ó Ö Ò Ø Î Æ Ìº ÅÓÖ ×Ô
ÐÐݸ Ø Ú ÐÙ × Ó M inT h Ò M axe2eDelay ¸ Û
Ú Ò ÙÔ Ø ÐÓÒ Ø Ô Ø ¸
ÓÒØ Ò Ø Ñ Ò ÑÙÑ Ø ÖÓÙ ÔÙØ Ò Ø Ñ Ü ÑÙÑ Ò ¹ ØÓ¹ Ò Ð Ý ÐÐÓÛ Ò Ø Ö Ñ Ò Ò Ô ÖØ Ó Ø Ô Ø ØÓ¹ Û Ö Ø ×Ø Ò Ø ÓÒº Ì Ö ÓÖ ¸ × ×
Ö Ò ×
Ø ÓÒ ÁÁÁ¸ Ø Ø Û Ý × Ð ØÓ ×Ø ÖØ Ò ÓØ Ø ÓÒ Ô × Û Ø Ø
ÓÖ Ò ØÛÓÖ ¸ ØÓ ×× ×× ØÛÓ × Ó ÒØ × Ø× Ó Ö ÕÙ Ö Ñ ÒØ× ´ µ ÉÓË
ÓÒ×ØÖ ÒØ× ØÓÛ Ö × ×Ø Ò Ø ÓÒ¸ º º Ø Ð ØÝ Ó Ø
ÓÖ Ò ØÛÓÖ ØÓ Ð Ú Ö ØÖ
ØÓ Ø ×Ø Ò Ø ÓÒ Û Ø Ò Ø Ñ Ü ÑÙÑ ØÓÐ Ö Ø Ð Ý Ò Ø Ø Ñ Ò ÑÙÑ Ö Ø ¹ ×Ö Ý Ø Ù× Ö ´ µ ÔÔÐ
Ø ÓÒ»Ù× Ö ÔÖ Ö Ò
׸ ÛÖ ØØ Ò Ò Ø Ë ÈÒ Ö Ó Ø ËÁÈ ÁÆÎÁÌ Ñ ×× ¸
ÓÒ
ÖÒ¹ Ò ÔÔÐ
Ø ÓÒ¹Ð Ý Ö ØÙÖ × ×Ù
× ÔÖ
Ò Ò ×
ÙÖ Øݺ ÁÒ ×Ù
Û Ý¸ Ø ØÛÝ × × ØÓ Ñ Ò ÐÓÛ¹Ð Ý Ö Ò ¹Ð Ý Ö ×Ô
Ø× Ø Ø × Ñ Ø Ñ ¸ Ò ÙÐÐÝ
ÖÓ××¹ Ð Ý Ö × ÓÒº Ö ÒØÐÝ ÖÓÑ Ø Ð
Ý ÔÖÓØÓ
ÓÐ ½¼℄¸ Û ÒØÖÓ Ù
ÎÁº ÉÓ˹ Û Ö ÖÓÙØ Ò ØÓÛ Ö Ø Û Ý× ÙÖØ Ö ÙÒ
×Ø ÖÓÙØ Ò Ñ ×× ¸
ÐÐ ÊÓÙØ ÓÒ ÖÑ Ø ÓÒ ´ ÇÆ ÁÊŵ¸ Ø Ø × ××Ù Ý Ø Ù× Ö ØÓÛ Ö ×
ÓÖ Ò ØÓ Ø ÔÖÓÔÓ× Ð ÔÖ × ÒØ Ò ½¼℄ ´Û
Ò Å ×× ÓÒ Ó Ø Ø Û Ý× ´ º º Ø Ò Ö ×Ø ÓÒ µ Ø Ø Ò×Û Ö Ø ÓÐÐÓÛ Ò Û ÐÐ Ö ÖÖ × Ç Î¹ÉÓ˵ Û ÜØ Ò Òݺ ÍÔÓÒ Ö
Ú Ò ÇÆ ÁÊÅ Ç Î· ¿℄ ÔÖÓØÓ
ÓÐ Ý Ñ Ò× Ó ØÛÓ Ø ÓÒ Ð Ð × Ò Ø ÊÓÙØ Ê ÕÙ ×ظ Ø Û Ý ÓÖÛ Ö × Ø ÓÖ Ò Ð ËÁÈ Ø ÊÊ É Ñ ×× º Ì Ó× Ð ×¸ Ò Ñ M inT h Ò Ñ ×× ¸ Ø × Ð
Ø ØÓ Ø ÜØ ÖÒ Ð Ò ØÛÓÖ ¸ Ò Ø ÑÙÐØ ¹ M axe2eDelay ¸
ÖÖÝ Ö ×Ô
Ø Ú ÐÝ Ø Ñ Ò ÑÙÑ Ø ÖÓÙ ¹ ÁÆÎÁÌ Ñ ×× Ñ × ×× ÓÒ ×Ø Ð × Ñ ÒØ
Ò
ÓÒØ ÒÙ º Ò Ø Ø¹ ÔÙØ Ò Ø Ñ Ü ÑÙÑ Ò ØÓ Ò Ð Ý ØÓÐ Ö Ø ÝØ ÇÆ ÁÊÅ Ñ ×× ÓÖ Ø Ù× Öº Ö ÒØÐÝ ÖÓÑ ½¼℄¸ Û Ö Ø ÔÖÓÔÓ× Ð × Ò Û Ý׸ Û
Ó ÒÓØ Ö
Ú Ú Ò Ø Ñ Ö¸ Ö × Ø Ø
ÙÖÖ ÒØ × ×× ÓÒ Ò Ø ¹ ÓÒ Ò Ô Ò ÒØÐÝ Ó Ø ÔÖÓØÓ
ÓÐ ÓÔØ ØÅ Ð Ý Ö¸ ÜÔ Ö Ø ÓÒ Ó Ò Ø ÔÖ × ÒØ ÛÓÖ Û
ÓÒ× Ö ¼¾º½½ × Î Æ Ì¸ Ø ÓÒ»ÖÓÙØ Ò ÔÖÓ
ÙÖ º Ø Ö ÓÖ Û Ú ÔÖ
Ø
Ð Û Ý ØÓ ×Ø Ñ Ø Ø Ð Ý ÇÒ
Ø × ×× ÓÒ × ×Ø Ð × ¸ Ø ÖÓÙØ Ò Ð Ý Ö Ó
Î Æ Ì ÒÓ ÐÓÒ Ø Ô Ø
ÓÒØ ÒÙÓÙ×ÐÝ ÑÓÒ ØÓÖ× ÓØ ×Ô ÒØ Ø Ú ÖÝ ÓÔ Ò Ø Ú Ð Ð Ø ÖÓÙ ÔÙØ ÐÓÒ Ø Ý Ø Ø Ô Ø ´× ×
Ø ÓÒ Îµº Ï ÙÖØ Ö
ÓÒ× Ö ÒÓØ Ö ¹ Ø ÉÓË Ô Ö ÓÖÑ Ò
Ô Ö Ñ Ø Ö× ÜÔÓÖØ Ø ÓÒ Ð Ð Ò Ø ÊÊ É Ñ ×× ¸ Ò Ñ ÐÝ ExpLif eT ime¸ Ä Ò Ä Ý Ö Ò Ø È Ý×
Ð Ð Ý Ö Ô Ö Ñ Ø Ö׺ Á Ø Ö ÙÖ Ò Ø ÖÓÙØ × ØÙÔ ÔÖÓ¹ Û
ÖÖ × Ò ÓÖÑ Ø ÓÒ
ÓÒ
ÖÒ Ò Ø ÜÔ
Ø ÖÓÙØ ÉÓË Ô Ö ÓÖÑ Ò
Ò ÓØ Ø
ÙÖ
Ò ÒÓ ÐÓÒ Ö Ñ Ø ÓÖ Ð Ò × Ö Ô ÐÝ Ó Ò ØÓ Ð ØÑ ¸ Ò Ò Û ÖÓÙØ Ò Ñ ×× ´ ÇÆ ÁÊŵ¸ Ò Ö ¸ Ø Ò Ø ××Ù × ÊÓÙØ ¹ Ð ÖØ Ñ ×× Ò ØÖ Ö× ØÓ
ÓÒ ÖÑ Ø × Ð
Ø ÓÒ Ó × Ò Ð Ø Û Ýº ÊÓÙØ ¹ÍÔ Ø ÔÖÓ
ÙÖ ¸ × ×
Ö Ò ×
Ø ÓÒ ÁÁÁ¹ º ÁÒ ÓÙÖ Ö Ñ ÛÓÖ ¸ Û Ò Ó×Ø ××Ù × ÊÊ É Ñ ×× ¸ Ø Ò Ø Ð × × M inT h Ò M axe2eDelay ØÓ Ø Ú ÐÙ × ×Ô
¹ Ì × ÔÖÓ
ÙÖ Ö ÕÙ Ö ×
ÓÒØ ÒÙÓÙ×
ÓÓÔ Ö Ø ÓÒ ØÛ Ò Ý Ø Ù× Ö¸ Ò × Ø× ExpLif etime ØÓ Ò Ò Øݺ Ì Ò¸ È Ý×
и Å »ÄÄ ¸ Ò Æ ØÛÓÖ Ð Ý Ö׺ Ø Ò× ÖØ× Ò Ø ÊÊ É Ñ ×× Ø Å Ð Ú Ð ÔÖ ÓÖ ØÝ i¸ ÎÁÁº Ì ×
Ö ÔØ ÓÒ Ó × ÖÚ
Ö ÕÙ Ö Ñ ÒØ×
Ó× Ò ØÓ ÓÖÛ Ö Ø ØÖ
¸ Ò Ø × Þ Ó Ø Ô
Ø× ÒØ Ò ØÓ × Òغ × Ö×Ø ÔÔÖÓÜ Ñ Ø ÓÒ¸ Û ××ÙÑ Ì Ë ÈÒ ÔÖÓØÓ
ÓÐ ¾℄ × Ò Ú ÐÓÔ × Ò ÜØ Ò¹ Ø Ø Ü ¹× Þ Ô
Ø× Ö × ÒØ Ý Ø ×ÓÙÖ
ÒÓ º × Ð Ö Ñ ÛÓÖ ¸ × ÓÒ ÅÄ ´ ÜØ Ò× Ð Å Ö ÙÔ Ä Ò¹
ÒÓ ÐÓÒ Ø Ô Ø Ö × Ø Ò Û Ð × Ò ÙÔ Ø × Ù µ¸ Ñ Ò Ø ×
Ö Ò ÑÙÐØ Ñ × ×× ÓÒ× Ò Ò Ó¹ Ø Ñ
ÓÖ Ò ÐÝ Û Ø Ø ×Ø Ñ Ø ÓÒ Ñ Û Ø
ÓÓÔ Ö¹ Ø Ø Ò Ò ¹ Ó×Ø
Ô Ð Ø ×º Ë ÈÒ × ×× ÓÒ ×
Ö ÔØ ÓÒ׸ Ø ÓÒ Ó Å Ò È Ý×
Ð Ð Ý Ö׺ ÅÓÖ ×Ô
ÐÐݸ Ø Ù×Ù ÐÐÝ Ñ Û Ø Ò × ×× ÓÒ Ò Ø Ø ÓÒ Ñ ×× ×¸ º º ×Ù ØÖ
Ø× ÖÓÑ M axe2eDelay Ø Ú ÐÙ DDLL,i ´× ×
¹ ËÁÈ Ñ ×× ×¸
Ò ÔÖÓÚ Û Ø Ò ÓÔØ ÓÒ Ð ×
Ø ÓÒ¸
UbiCC Journal – Volume 3
19
ÐÐ Ë ×× ÓÒ ÁÒ ÓÖÑ Ø ÓÒ¸ Ö × ÖÚ ØÓ ×Ô
Ý Ø ÓÒ Ð Ø ÓÙØ Ø × ×× ÓÒº Ï ÔÖÓÔÓ× ØÓ ÐÐ Ô
Ø× ÐÓÒ Ò ØÓ ËÁÈ × ×× ÓÒ Ò ¹ Ø Ø ÓÒ ÔÖÓ
ÙÖ ÖÓÑ Î Æ Ì ÒÓ Û Ø ¹Ð Ý Ö Ù× Ö» ÔÔÐ
Ø ÓÒ ÔÖ Ö Ò
×
Ð Ö Ø ÖÓÙ Ë ÈÒ ¸ Ò Ø Ò ØÓ
ÖÖÝ Ø × Ô
Ø× ÒØÓ Ç Î ÖÓÙØ ×
ÓÚ ÖÝ Ô
Ø׺ Ì Ö ÓÖ ÊÊ É Ñ ×× ×
ÓÒØ Ò× ÓØ Ò ÐÓÛ¹Ð Ý Ö Ô Ö Ñ Ø Ö׺ × ÑÔÐ Ë ÈÒ ×
Ö ÔØ ÓÒ
ÓÙÐ Ò
ÐÙ Ø ÓÐÐÓÛ Ò ¹Ð Ý Ö Ô Ö Ñ Ø Ö׸ Û
ÐÔ Ø Ø Û Ý× ØÓ
ÓÓ× Ò ÜØ ÖÒ Ð Ò ØÛÓÖ ØÓ Ø ÁÒØ ÖÒ Ø ´ µ ÔÖ ÖÖ × ÖÚ
ÔÖÓÚ Ö× Ø Ù× Ö × ×Ù ×
Ö Ò Ö Ñ ÒØ Û Ø ´ µ ×
ÙÖ ØÝ Ò ÔÖ Ú
Ý Ð Ú Ð¸ Ö ÔÖ × ÒØ Ò Ø Ù× Ö Ö ÕÙ Ö ¹ Ñ ÒØ× ÓÒ Ø
ÓÒ ÒØ Ð ØÝ ´ µ Ñ Ü ÑÙÑ
Ó×Ø Ø Ù× Ö × Û ÐÐ Ò ØÓ Ô Ý ÓÖ Ø Ö ÕÙ Ö × ÖÚ
¸ ÜÔÖ ×× Ø ÖÓÙ ×Ù Ø Ð Ñ ØÖ
º
ÎÁÁÁº ÓÑÔ Ö Ò Ð
Ý Ò ÔÖÓÔÓ× ÔÔÖÓ
×
Ø Û Ý ØÝÔ Ð ×× ½
ÉÓË Ñ Ò
Ô Ö ÓÖ¹
Ó×Ø ½¼
ÈÖÓÚ
Ö
Ë
ÙÖ ØÝ Ä Ú Ð ½
½º Å »×¸ ¼º¿×
Ö Ñ ÒØ× Û Ø ÐÐ ÔÖÓÚ Ö× ÔÖÓÚ½º
ÓѸ ÔÖÓÚ¾º
ÓÑ ÓÒÐÝ
Ð ×× ¾
¿
»×¸ ¼º¼ ×
½
Ð ×× ¿
»×¸ ¼º½×
¾
Ö Ñ ÒØ× Û Ø ÐÐ ÔÖÓÚ Ö×
½
Ë ÑÙÐ Ø
ÐÓÛ ÚÓ
Ú Ó Å Ü ÑÙÑ Ò ¹ØÓ¹ Ò Ð Ý
Ø Û Ý×
Å Ò ÑÙÑ Ø¹Ö Ø »× ½ ¾ »×
Ì
Ä
Á
Ö
Ø Ö ×Ø
×
Ê ÕÙ Ö ÔÖÓÚ Ö ÔÖÓÚ½º
ÓÑ ÔÖÓÚ¾º
ÓÑ Å Ü ÑÙÑ
Ó×Ø ¿ ½¼ Ë
ÙÖ ØÝ Ä Ú Ð ½ ½
¼º½¾ × ¼º ×
Ê ÕÙ Ö Ñ ÒØ× Ó Ø ÉÓË × Ò× Ø Ú ÐÓÛ×
Ì
Ä
ÁÁ
ÁÒ Ø × ×
Ø ÓÒ Û ÔÖ × ÒØ × ÑÙÐ Ø ÓÒ
ÑÔ Ò¸
Ö¹ Ö ÓÙØ Ø ÖÓÙ Ò×¾ ´Æ ØÛÓÖ Ë ÑÙÐ ØÓÖ Ú¾µ ØÓ ×× ×× Ø Ô Ö ÓÖÑ Ò
Ó Ø ÔÖÓÔÓ× ÖÓÙØ × Ð
Ø ÓÒ ÔÔÖÓ
º Ï
ÓÑÔ Ö ÓÙÖ ×ÓÐÙØ ÓÒ¸ Ò Ø ÓÐÐÓÛ Ò Ö ÖÖ ØÓ × ÀÇ ÔÖ
Ø ÓÒ¸ Û Ø ØÛÓ Ö Ö Ò
Ð ÓÖ Ø Ñ× Ð
Ý Ç Î¹ × Ø Û Ý ×
ÓÚ ÖÝ ÔÔÖÓ
¸ ÔÖÓÔÓ× Ò ¿℄¸ Û
Ó × Ò Ø Ö ÑÔÐ Ñ ÒØ ×Ñ ÖØ Ø Û Ý × Ð
Ø ÓÒ ÒÓÖ Ò ÓÚ Ö Ñ Ò Ñ ÒØ ×ØÖ Ø ×¸
ÐÐ Ð
Ý Ò × Ñ¹ ÔÐ Ú Ö× ÓÒ Ó ÓÙÖ ×ÓÐÙØ ÓÒ¸ Ø Ø ÔÔÐ × Ø Û Ý × Ð
¹ Ø ÓÒ ÙØ Ó × ÒÓØ Ð ÛØ ÖÐÝ Ò ÓÚ Ö Ø
Ø ÓÒ¸ Ò Ø ÓÐÐÓÛ Ò
ÐÐ ÌÏ × Ð
Ø ÓÒ ÓÒÐݺ Ä Ø³×
ÓÒ× Ö × ÑÔÐ ÙÖ Ò ×
Ò Ö Ó¸
ÓÒ× ×Ø Ò Ó ½½¼ ÖÓ × Ò ÒØ Ö×
Ø ÓÒ׸ Û
ÑÓ Ð× ½¾¼¼Ñ¶ ¼¼Ñ Û ÔÓÖØ ÓÒ Ó Ê Ó Ð Ö ³× × ÖÓÒØ ÖÓ Ò ØÛÓÖ º × Ø ÔÖÓÔ Ø ÓÒ ÑÓ Ð¸ Û Ù× Ø ØÛÓ¹Ö Ý ÖÓÙÒ Ö ¹
Ø ÓÒ ÑÓ Ð ÔÖÓÚ Ý Ò×¾º Î
Ð × Ö ×ÙÔÔÓ× ØÓ ØÖ Ú Ð Ø Ô
Û ×
ÓÒ×Ø ÒØ ×Ô ×¸ Ö Ò Ò ØÛ Ò ¿ Ò Ñ»×¸
ÓÖ Ò ØÓ Ø ÑÓ Ð ØÝ ÑÓ Ð ÔÖÓÔÓ× Ò ½½℄º Ï
ÓÒ× Ö Ø Ø ½¼ Ú
Р׸ Ö Ò ÓÑÐÝ
Ó× Ò ÑÓÒ ¼ Ú
Ð × ÑÓÚ Ò Ò Ø × ÑÙÐ Ø ÓÒ ×
Ò Ö Ó¸ ÓÖ Ò Ø ÉÓË × Ò× Ø Ú ÓÛ× Ö
Ø ØÓÛ Ö ÜØ ÖÒ Ð Ó×Ø׸ Û Ò Ò ÔÖ ×¹ Ò
Ó Ö ÒØ Ø Û Ý׺ ËÔ
ÐÐݸ Û × ÑÙÐ Ø Ø Ö Ò × Ó Ø Û Ý× ´× Ì Ð Áµ¸ Ò×Ø ÐÐ Ø Ü ÐÓ
Ø ÓÒ× Ð ×× ½ Ø Û Ý×
Ø × ÖÓ Ò Ü ÈÓ ÒØ× Ç ÈÖ ×¹ Ò
´ÈÇȵ ÓÖ Ñ Ò Ò
Ù×ØÓÑ Ö׸ º º Ø ×Ó¹
ÐÐ Óع×ÔÓØ× Ð ×× ¾ Ø Û Ý× Ö ÔÖ × ÒØ ÈÇÈ× × Û Ðи Ò Ö Ð ØÓ Ù Ö ÒØ ÐÓÛ Ö Ø¹Ö Ø × ÙØ ×ØÖ
Ø Ö Ð Ý
ÓÒ×ØÖ ÒØ× Ð ×× ¿ Ø Û Ý× Ó Ö ÑÓÖ Ð Ñ Ø Ò ØÛÓÖ Ö ×ÓÙÖ
׺ ÇØ Ö Ô Ö Ñ Ø Ö× Ò Ì Ð Á
ÓÙÒØ ÓÖ Ø ¹Ð Ý Ö
Ô Ð Ø × Ó Ø Ø Û Ý× ´ º º¸ ÑÓÒ Ø ÖÝ
Ó×Ø Ó Ø
ÓÒÒ
Ø ÓÒ¸ Ö Ñ ÒØ Û Ø ÔÖÓÚ Ö׸ Ò ×
ÙÖ ØÝ Ö µº ÓÖ Ø × Ó × ÑÔÐ
Øݸ Ø
Ú Ð ÉÓË Ò ÜØ ÖÒ Ð Ò ØÛÓÖ × × Ö ÔÖ × ÒØ Û Ø Ü ØÖ Ø× Ò Ð Ý׺ Ì × ××ÙÑÔØ ÓÒ¸ ÐØ ÓÙ ÒÓØ ØÓØ ÐÐÝ Ö Ð ×Ø
¸ й ÐÓÛ× Ù× ØÓ Ó
Ù× ÓÒ Ø Ñ Ò ××Ù Ó Ø × Ô Ô Ö¸ º º ÓÛ ÉÓ˸ ÖÓÙØ Ò Ò Ø Û Ý × Ð
Ø ÓÒ Ö Ô Ö ÓÖÑ Û Ø Ò Ø
×× Ò ØÛÓÖ ¸ Ö Ø Ö Ø Ò ÒÚ ×Ø Ø Ò ÓÛ Ø Ý Ö
ÓÑÔÐ × ÓÙØÛ Ö º Ö
Ø Ö ×Ø
× Ó Ù× Ö» ÔÔÐ
Ø ÓÒ× Ò ÉÓË Ö ÕÙ Ö Ñ ÒØ× Ó Ü
Ò ÓÛ× Ö Ö ÔÓÖØ Ò Ì Ð ÁÁº Ì Ö×Ø
Ð ×׸
Ö ÔÖ × ÒØ Ò ÚÓ
Ðи × × ÓÖ ÐÓÛ Ò ¹ØÓ¹ Ò Ð Ý Ò ÐÓÛ Ø¹Ö Ø Ø × ÑÓ Ð × »× ÓÒ×Ø ÒØ Ø Ê Ø ´ ʵ ÓÛº Ì ×
ÓÒ
Ð ×׸ Ö ÔÖ × ÒØ Ò Ú Ó ×ØÖ Ñ¹ Ò ÔÔÐ
Ø ÓÒ¸ Ò × Ö Ø¹Ö Ø ÙØ ØÓÐ Ö Ø × Ð ×× ×ØÖ
Ø Ð Ý׸ Ò × ÑÓ Ð Ø ÖÓÙ ½ ¾ »× Ê ÓÛº Ï ÙÖØ Ö ÒØÖÓ Ù
Ú Ö Ð ÑÓÙÒØ Ó
ÖÓÙÒ ØÖ ¹
¸ Ü
Ò ØÛ Ò
ÓÙÔÐ × Ó Ú
Ð × Ò Ø Î Æ Ì¸ ÑÓ Ð × ¿¾ »× Ê ÓÛ׸ ØÓ Ø ÔÙÖÔÓ× Ó Ú Ö Ý¹ Ò Ø ÑÔ
Ø Ó Ö ÒØ Ò ØÛÓÖ ÐÓ × ÓÒ Ø
ÓÒ× Ö Ð ÓÖ Ø Ñ׺ ÓÖ
ØÖ
Ð ×׸ Ð×Ó ¹Ð Ú Ð Ö ÕÙ Ö ¹ Ñ ÒØ× Ö
ÓÒ× Ö Ò Ì Ð ÁÁ Ø × Ö Ø ÔÖ ÖÖ ÔÖÓÚ Ö¸ Ø Ñ Ü ÑÙÑ
Ó×Ø Ø Ù× Ö × Ú Ð Ð ØÓ Ô Ý ÓÖ Ø
ÓÒÒ
Ø ÓÒ¸ Ò Ø Ö Ó ×
ÙÖ ØÝ Ö ÕÙ Ö º Ë ÑÙÐ Ø ÓÒ׸
ÓÒ Ð ×Ø Ò ¿¼¼ ×
ÓÒ ×¸ Ö Ö Ô Ø ½¼ Ø Ñ × Ý Ú ÖÝ Ò Ø ÑÓ Ð ØÝ Ô ØØ ÖÒ׸ Ø ÒÙÑ Ö Ó Ú Ð¹ Ð Ø Û Ý׸ Ò Ø ÑÓÙÒØ Ó
ÖÓÙÒ ØÖ
º Ú¹ Ö Ñ ×ÙÖ × Ö Ö ÔÓÖØ ØÓ Ø Ö Û Ø Ø Ö Ð Ú ÒØ ±
ÓÒ Ò
ÒØ ÖÚ Ð׺ Ï Ø Ö Ö Ò
ØÓ ÉÓË ÓÛ׸ Ø ÚÖ ØÖ Ø Ó Ô
Ø× ÖÖ Ú Û Ø Ò Ø
ÓÑÑ ØØ Ò ¹ØÓ¹ Ò Ð Ý ÓÙÒ × × × Ð
Ø ×
ÓÑÔÖ Ò× Ú Ô Ö¹ ÓÖÑ Ò
Ñ ØÖ
º ÁØ Ú × Ò ÓÖÑ Ø ÓÒ ÓÒ ÓØ Ø ÖÓÙ ÔÙØ Ò Ð Ý׺ Ê ×ÙÐØ× Ö Ö ÔÓÖØ Ò º ¿ Û Ò Ú Öݹ Ò Ø ÑÓÙÒØ Ó
ÖÓÙÒ ÓÛ׸ Û
ÓÑÔ Ø Û Ø ÉÓË × Ò× Ø Ú ØÖ
Ò Ø Î Æ Ìº × ÜÔ
Ø ¸ Ò¹Ø Ñ Ð Ú ÖÝ Ö Ø × Ó ÉÓË × Ò× Ø Ú ÓÛ×
Ö × Û Ø ÖÓÛ¹ Ò ÔÖ × Ò
Ó
ÓÑÔ Ø Ò
ÖÓÙÒ ØÖ
º ÀÓÛ Ú Ö¸ ÓÙÖ ×ÓÐÙØ ÓÒ Ô Ö ÓÖÑ× ØØ Ö¸ Û Ø Ö ×Ô
Ø ØÓ ÓØ Ð
Ý Ò ÌÏ × Ð
Ø ÓÒ ÓÒÐÝ ÓÒ ×¸ Û Ø ÐÐ Ò ØÛÓÖ ÐÓ ×º Ï
Ò ÜÔÐ Ò ×Ù
Ö ×ÙÐØ× Ý ÒÓØ
Ò Ø Ø¸
ÓÖ Ò ØÓ Ø
ÓÒ× Ö ÓÛ
ÓÒ×ØÖ ÒØ× Ò Ø Û Ý×
Ö
Ø Ö¹ ×Ø
׸ Ú Ó ÓÛ×
Ò ÕÙ Ø ÐÝ × ÖÚ Ý Ø Û Ý× Ó Ð ×× ½ ÓÒÐݸ Û Ð ÚÓ
ÓÛ× Ò Ð ×× ¾ Ø Û Ý× ØÓ
ÓÑÔÐ × Ø Ö
ÓÑÑ ØÑ ÒØ׺ Ä
Ý ÔÔÖÓ
Ò ¹ Ø Ö Ô Ý× ØØ ÒØ ÓÒ ÓÒ ÉÓË Ô Ø × Ò Î Æ Ì ÒÓÖ ÓÒ Ø × Ð
Ø ÓÒ Ó Ø ×Ø Ø Û Ý× ÑÓÒ Ø Ó× ÔÖ × Òظ Ò Ø Ò ×ØÖ ÙØ × ÉÓË ØÖ
Ú ÒÐÝ ÑÓÒ ÐÐ Ø Ú Ð Ð Ø Û Ý׺ Ì Ù׸ Ø
Ò ÒÓØ Ó Ö Ø Ö ÕÙ ×Ø Ù Ö ÒØ ×º ÙÖØ Ö¸ Ý
ÓÑÔ Ö Ò Ø ÔÖÓÔÓ× Ò ÓÚ Ö Ø
Ø ÓÒ ×ØÖ Ø Ý Û Ø Ø ÌÏ × Ð
Ø ÓÒ ÓÒÐÝ ÔÔÖÓ
¸ Û ×¹ ØÒ Ù× Ø ØØ Ò ÓÚ Ö
ÓÒØÖÓÐ Ò Ø Î Æ Ì ÔÖÓÚ ×
UbiCC Journal – Volume 3
20
Average in-time delivery rates for video and voice flows (b/s)
Average in-time delivery rates for video and voice flows (b/s)
Video flows (b/s)
Video flows (b/s)
160000
120000
80000
40000
0
160000
120000
80000
40000
0
0
96
192
1; 1; 8
2; 2; 6
3; 3; 4
Voice flows (b/s)
Voice flows (b/s)
8000
6000
4000
2000
0
8000
6000
4000
2000
0
0
96 Background traffic (kb/s)
192
1; 1; 8
2; 2; 6 Number of gateways of each class (Class 1, 2 and 3)
3; 3; 4
voice legacy voice HO_prediction
voice GTW_selection_only
video legacy video HO_prediction
video GTW_selection_only
º ¿º
ÁÒ¹Ø Ñ ÖÓÙÒ ØÖ
Ð Ú ÖÝ Ö Ø ×
ÓÖ ÉÓË
ÓÛ׸ Ú ÖÝ Ò
Ø
ÑÓÙÒØ Ó
º
º
ÁÒ¹Ø Ñ
Ð Ú ÖÝ Ö Ø × ÓÖ ÉÓË
ÓÛ׸ Ú ÖÝ Ò
Ø Û Ý׳
Ö¹
Ø Ö ×Ø
×
Ò
Ð
Ø ÓÒ Ø ÓÚ Ö ÐÐ Ô Ö ÓÖÑ Ò
¸ Ú Ò Û Ò
ÖÓÙÒ ØÖ
Ò
Ö × ×º Ö ÒØÐݸ Ò ×Ù
ÓÒ Ø ÓÒ× Ø ÌÏ × Ð
Ø ÓÒ ÓÒÐÝ ×ÓÐÙØ ÓÒ Ö × Ð×Ó Û Ø Ö ¹ ×Ô
Ø ØÓ Ð
ݸ × Ò
Ø ÐÓ× × ÑÙ
Ø Ñ Ò Ø × Ö
ÓÖ ×Ù Ø Ð Ô Ø × Ø Ö ÖÓÙØ Ö Ú ÒØ׺ ÁÒ º Û Ò ÐÝÞ ÓÛ Ø ÔÖ × Ò
Ó Ø Û Ý× Û Ø Ö ÒØ
Ö
Ø Ö ×Ø
× ÑÔ
Ø× ÓÒ Ø
Ô Ð ØÝ ØÓ × ÖÚ ÉÓË ÓÛ׺ Ï Ð Ô Ò Ø ØÓØ Ð ÒÙÑ Ö Ó Ø Û Ý× ÔÐÓÝ Ò Ø × ÑÙÐ Ø ÓÒ Ö Ü ØÓ ½¼¸ Û Ú ÖÝ Ø ÔÖÓÔÓÖØ ÓÒ Ó Ø Û Ý× ÐÓÒ Ò ØÓ Ø Ø Ö
Ð ×× × ¹ ×
Ö ÓÚ ´Û Ö
ÐÐ Ø Ø Ð ×× ½ Ò ¾ Ø Û Ý× Ó Ö Ö ØÙÖ × Ø Ò Ð ×× ¿ ÓÒ ×µº ÇÒ Ø Ü¹ Ü × Û Ö ¹ ÔÓÖØ Ø Ö Ö ÒØ
ÓÒ ÙÖ Ø ÓÒ׸
Ö
Ø Ö Þ Ø ÖÓÙ Ø ÒÙÑ Ö Ó Ø Û Ý× Ó
Ð ×× ÔÐÓÝ Ò Ø × Ñ¹ ÙÐ Ø ÓÒ ×
Ò Ö Óº × Û
ÓÙÐ ÜÔ
ظ Ø Ô Ö ÓÖÑ Ò
ѹ ÔÖÓÚ × Û Ò Ò
Ö × Ò Ø ÒÙÑ Ö Ó Ð ×× ½ Ò Ð ×× ¾ Ø Û Ý׸ º º Ø ÑÓ×Ø Ú ÐÙ Ð ÓÒ ×º ÀÓÛ Ú Ö¸ Ö¹ Ö ×Ô
Ø Ú Ó Ø ÔÖ × Ò
Ó Ø Û Ý× Û Ø Ö ÒØ Ò ØÙÖ ¸ Ø ÔÖÓÔÓ× ÔÔÖÓ
ÓÙØÔ Ö ÓÖÑ× ÓØ Ð
Ý Ò ÌÏ × Ð
Ø ÓÒ ÓÒÐݺ ÙÖØ ÖÑÓÖ ¸ Ú Ò Ø Ø ÓÙÖ Ð ÓÖ Ø Ñ × Ø Û Ý × Ð
Ø ÓÒ Ò ÉÓË ÖÓÙØ Ò Ò Ø Î Æ Ì Ò
ÓÑÑÓÒ ØÓ ÌÏ × Ð
Ø ÓÒ ÓÒÐݸ Ø ÑÔÖÓÚ ¹ Ñ ÒØ Ò Ô Ö ÓÖÑ Ò
× Ú ÒØÐÝ Ù ØÓ Ø ÑÔÐ Ñ ÒØ Ô Ø × Ð
Ø ÓÒ ×ØÖ Ø ×¸ Ø Ø ÐÐÓÛ ÓÖ ÖÐÝ Ø
Ø ÓÒ Ò Ö Ô Ö Ó ÖÓ Ò Ð Ò ×º Ï Ú Ð×Ó Ú ÐÙ Ø Ø ÓÚ Ö ÒØÖÓ Ù
Ý
ÔÖÓØÓ
Óи
ÓÒ× Ö Ò Ø Ö
Ø ÓÒ Ó Ø × Ò Ð Ò Ö Ð Ø ØÖ
Û Ø Ö ×Ô
Ø ØÓ Ø ØÓØ Ð ØÖ
Ò¹
Ø ÒØÓ Ø Ò ØÛÓÖ º Ï
Ò Ó × ÖÚ Ø Ø Ø ÓÚ Ö ÒØÖÓ Ù
Ý ÓÙÖ ÔÖÓÔÓ× Ð × ÓÙØ ½º Ø Ñ × Ø ÓÒ Ó Ø Ð
Ý ÔÔÖÓ
¸ Û Ð Ø ÌÏ × Ð
Ø ÓÒ ÓÒÐÝ Ô¹ ÔÖÓ
ÒØÖÓ Ù
× ÓÙØ ½º¾ Ø Ñ × Ø ÓÚ Ö Ó Ð
ݸ
Ù× Ø × Ú × Ø × Ò ÐÐ Ò Ü
Ò Ö Ð Ø ØÓ Ø ÖÐÝ Ò ÓÚ Ö Ø
Ø ÓÒº
Á º ÓÒ
ÐÙ× ÓÒ×
Ø Ö Ø × Ñ ÓÖ Ö ÒØ × ÖÚ
ÔÖÓÚ Ö׺ Ï ÔÖÓÔÓ× Ö Ñ ÛÓÖ × ÓÒ
ÖÓ××¹Ð Ý Ö ÔÔÖÓ
ØÓ ÔÖÓÚ ÁÒØ ÖÒ Ø
ÓÒÒ
Ø Ú ØÝ Ò Ò ¹ØÓ¹ Ò ÉÓË ØÓ Ø Ú
Р׺ Ì × Ø × × Ö Ô Ö ÓÖÑ Ý ´ µ × ØØ Ò ÙÔ ÑÙÐØ Ñ × ×¹ × ÓÒ× ÖÓÑ Î Æ Ì ÒÓ × ´ µ Ö
Ø Ú ÐÝ Ù Ð Ò ÉÓË Ò Ø¹ ÛÓÖ Ô Ø × Ò Ø Î Æ Ì ´ µ × Ð
Ø Ò Ø ×Ø Ú Ð Ð Ø Û Ý ÓÖ ÓÙØÛ Ö ØÖ Ò×Ñ ×× ÓÒ¸
ÓÖ Ò ØÓ Ò ØÛÓÖ Ö ×ÓÙÖ
Ú Ð Ð ØÝ Ò
ÓÑÔÐ Ò
Û Ø Ù× Ö» ÔÔÐ
Ø ÓÒ Ö ÕÙ Ö Ñ ÒØ׸ Ò ´ Úµ
ÓÒ×Ø ÒØÐÝ Ñ ÒØ Ò Ò Ò ÙÔ Ø¹ Ò ÖÓÙØ × ØÓ Ø Ø Û Ý׺ Ë ÑÙÐ Ø ÓÒ Ö ×ÙÐØ× Ò ÙÖ Ò ×
Ò Ö Ó× × ÓÛ Ø Ø Ø ÔÖÓ¹ ÔÓ× ÔÔÖÓ
Ò Ð ØÓ ØØ Ö ÓÚ Ö ÐÐ Ô Ö ÓÖÑ Ò
¸ Ò Ø ÖÑ× Ó Ø ÖÓÙ ÔÙØ Ò Ð Ý¸ Ø Ò Ø Ð
Ý ÓÒ º
Ê
½℄ ú º ÏÓÒ ¸ ú Ì Ô ¸ Ϻ ÓÑÑÙÒ
Ø ÓÒ׸ ×Ô
Ï Ö Ð ×× Ç
ØÓ ¾℄
Ô ¿℄ º ÑÙÒ
Ø ÓÒ׸ Ö ¾¼¼ º Ö¸ º ÇØظ ÓØ Ò º ÓÖÑ ÒÒ¸ Ë ×× ÓÒ Ì ¸ Û ¸ Ð Ö ×
Ö ÔØ ÓÒ Ø¹ Ò Ð ØÝ Ò ºÈ Ö Ø ÓÒ¸ Ì
º Ê Ôº¸ Á Ø ¹ÑÑÙ×
¹ Ò º º º ÃÙØ×
Ö Ò
×
Ò¸ Ò Åº ÖРغ¸ Á ¸
Á
Ï Ö Ð ××
ÓÑÑÙÒ
Ø ÓÒ׸
Ð ××Ù
ÓÒ ÁÒØ Ö¹Ú
ÙÐ Ö
Óѹ
ÚÓк ½¿¸ ÒÓº
× ÔÒ ¹¼ ºØÜظ ÏÓÖ ÌÙÓÑ Ò Ò¸ ÁÒØ ÖÒ Ø
Ò ÈÖÓ Ö ×׺ º Æ Ð××ÓÒ¸ ÓÒÒ
Ø Ú ØÝ ÓÖ ÅÓ ÀÓ
Æ ØÛÓÖ ×¸ ¸ ¸ ÒÓº ¾¸ ÔÔº ËØÙ Ý ÓÒ Ø ¹ Ó
Æ ØÛÓÖ ×¸ Ò× Ó
Ò׸ º ̺ Å Ð Ò Ò¸ ʺ Ï
Ï Ö Ð ××
×
¾¸ ¾¼¼¾º
ÓÑÑÙÒ
Ø ÓÒ× Ò ÅÓ Ð
ÓÑÔÙØ Ò
Ö ¸ ź Ð ÖÛ Ð¸ Ò Äº Ó¸
ÙÐ Ö Ø Û Ý× ÓÖ Î ÉÓË
℄
κ Æ Ñ ÓÓ Ò
℄
˺ Ë Ð× ÒÓ ¾¼¼¾º
ÁÒ ÈÖÓ
º Ó Î Æ Ì¼ ¸ Ç
ØÓ Ö ¾¼¼ ¸ È Ð
Ò Äº Î ÐØÖ ¸ × Ð ¸ Ê ÓÒØÖÓÐ ÔÔÐ
Ø ÓÒ׸ Ì ¾ ÇÈË ´
Ð ØÝ Ó ÅÓ
ËÙÔÔÓÖØ ËÁȹ ℄ ℄ ℄ º Ë Ô ¾¼¼¾º º Á Ö ¸ ÙÖ Ñ Á غ Ì
Á
Æ ØÛÓÖ
Ý Å
ÐÔ
´ÍË µº
ÇÈË ØÓ ÔÖ Ð
¸ Å Ö
»
ÓÑÑÓÒ ÇÔ Ò ÈÓÐ
Ý Ë ÖÚ
µ Ì
º Ê Ôº Ê ¿¾ ½¸ Á ¸ Ò Ì ¸
ÈÖÓØÓ
Óи
¸  ÒÙ ÖÝ ¾¼¼¼º
Ë ×× ÓÒ Ò Ø
Ø ÓÒ ÔÖÓØÓ
Óи º ÊÙ
º ÅÓÐ Ò ÖÓ¸ ×× ÒÑ ÒØ Ò ¸ ÆÓÚ Ñ
Ö ¸
Ò
º ÌÖ ÔÓ
℄
Ç
Á
ÔÖ ÓÖ ØÝ
ÐÓ
ÓÑ ¼
µ Ò
¼¾º½½ Ö ¾¼¼ º Ï Ö Ð ×× Ä Ë ÖÚ
º º È Ö Ñ Ò
¹ Ó
Ò ØÛÓÖ ×¸ Æ Å µ ËÔ
´ÉÓ˵¸ Ò׸ ×Ø Ò
ÙÑ
ÁÒ ÈÖÓ
º
ÓÒØÖÓÐ
ÝÒ Ñ
¼¾¸ Ô ÖØ ½½
×× Å
´Å ×Ø ½¼℄
È Ý×
Ð Ä Ý Ö ´ÈÀ ÓÖ ÉÙ Ð ØÝ Ó ¸ ¾¼¼ º Ò Ó
ÓÒ¹ Ò ¹ÊÓÝ Ö
Ø ÓÒ×
Ò¹
Ò
Ñ ÒØ× ¼¾º½½ ¸ Á Ð º ź ØÓ
Óи ÂÙÐÝ ¾¼¼¿º ½½℄ º ú Ë ÙÐ Ö
Ì
º Ê Ôº Á ÚÓÐÙØ ÓÒ Ò ÙØÙÖ ÔÖÓ¹ ½ ¼¸
¹
Ì Ö Ö Ò
×
Ò Ö Ó Ö ÔÓÖØ Ò Ø × Ô Ô Ö
ÓÒ× Ö× ÔÙ Ð
ØÖ Ò×ÔÓÖØ Ú
Ð × Ò
Ö× ØÖ Ú ÐÐ Ò ÐÓÒ ÙÖ Ò Ò ×Ù ÙÖ Ò ÖÓ × Ù× Ö Ø ÖÑ Ò Ð× ÓÒ Ó Ö Ø Ú ¹
Ð ×
Ò Ò Ø ÖÓÑ Ø ÔÖ × Ò
Ó Ø Ö ÓÒ ÓÖ ÑÙй Ø ÔÐ Ø Û Ý× Ò Ø Ö Ö Ó ÔÖÓÜ Ñ Øݺ Ø Û Ý×
Ò Ù× ØÓ ÜÔÐÓ Ø Ö ÒØ
×× Ø
ÒÓÐÓ × ÔÖÓÚ Ý ¹
Ö
Ø ÓÒ× Ó Ø
ÀÓ
Æ ØÛÓÖ × ÂÓÙÖÒ Ð¸
Ò º º ÂÓ Ò×ÓÒ¸
Ú
ØÓÖ ÖÓÙØ Ò
ÚÓк ½¸ ÒÓº ½¸ ÔÔº ½¾ Ð Ò ÑÓ Ð ØÝ ÓÖ Ú
Î
ÙÐ Ö
¹ Ó
Ò ØÛÓÖ ×¸
ÁÒ ÈÖÓ
º Ó Ø Ó
Ò ØÛÓÖ ×º È Ð ÐÔ
ÅÓ
Ö×Ø Å ÛÓÖ × ÓÔ ÓÒ ¸ È ¸ ÍË ¸ Ç
غ ¾¼¼ º
UbiCC Journal – Volume 3
21
VEHICULAR NETWORKS DEPLOYMENT VIEW: APPLICATIONS, DEPLOYMENT ARCHITECTURES AND SECURITY MEANS
Hassnaa Moustafa and Gilles Bourdon France Telecom R&D (Orange Labs) 38-40 rue du General Leclerc, 92794 Issy les Moulineaux Cedex 9, France {hassnaa.moustafa, gilles.bourdon}@orange-ftgroup.com
ABSTRACT Inter-Vehicle Communication (IVC) is attracting a considerable attention from the research community and the automotive industry, where it is beneficial in providing Intelligent Transportation System (ITS) as well as drivers and passengers’ assistant services. In this context, vehicular networks are emerging as a new class of wireless networks, spontaneously formed between moving vehicles equipped with wireless interfaces that could be of homogeneous or heterogeneous technologies. The recent advances in wireless technologies and the current trends in ad hoc networks scenarios allow a number of possible architectures for vehicular networks deployment. In this paper, we give a deployment view for vehicular networks illustrating its potential services. We present the possible deployment architectures of these networks and some promising wireless technologies, and we discuss some technical challenges for the deployment of these networks with a main focus on the security problem.
Keywords: Vehicular networks, deployment Architectures, on-board Services, wireless technologies, security.
1
INTRODUCTION AND BACKGROUND
Currently, Inter-Vehicle Communication Systems (IVCS) are widely discussed, attracting a considerable attention from the research community as well as the automotive industry [1]. In this context, vehicular networks are emerging as a new class of wireless networks enabling mobile users in their vehicles to communicate to the roadside and to each other. Vehicular networks are also promising in being a concrete application for ad hoc networks. These networks have special behavior and characteristics, distinguishing them from other types of networks: the nodes' (vehicles') mobility is high and may reach up to 200Km/h, the topology is dynamic but constrained by roads' topology, these networks may scale to a very large number of nodes (vehicles) according to the traffic condition and are expected to have a potentially heterogeneous administration. In this context, we consider that vehicular communication, opposing the wireless mobile communication, does not suffer from resource limitations (energy, CPU, memory, etc.) as vehicles are not tiny nodes and are capable of providing unlimited resources.
There exist two potential classes of services for vehicular networks [2]: i) ITS (Intelligent Transportation System) services and ii) passengers oriented non-ITS services. ITS services was the target of the primary works on inter-vehicular communication [3, 4, 5], aiming to minimize accidents and improve traffic conditions through providing drivers and passengers with useful information (ex. road conditions alarms, congestions alarms, fire alarms, and accident-ahead warnings, speed limit reminder, messages' exchange to avoid collision at intersection and messages' exchange to optimize traffic flows and to avoid crash situations). On the other hand, passengers oriented non-ITS services aim at providing commercial and leisure services and have been the target of some recent research contributions in this domain [6]. Such services mainly concern providing passengers and drivers with Internet connections facility exploiting an available infrastructure in an “on-demand” fashion. Other examples of useful services are: electronic tolling system, multimedia services (games on networks, VoIP and streaming), email access, and file sharing.
UbiCC Journal – Volume 3
22
Vehicular networks’ special behavior and characteristics together with the different types of potential services in these networks create some technical challenges that can impact the future deployment of these networks. In general, scalability and interoperability represent two important challenges. The employed protocols and mechanisms should be scalable to a numerous number of vehicles, and interoperable with different wireless technologies. In spite of the dynamic topology and the high mobility, reliable messages' exchange should be satisfied. Consequently, messages’ dissemination should be efficient and should adapt to the vehicular communication characteristics as well as the type of services. This should allow low communication latency between communicating vehicles in order to guarantee: i) service’s reliability, taking into consideration the time-sensitivity, for ITS services, and ii) the quality and continuity of service for passenger-oriented non-ITS services. We notice that messages’ dissemination should vary according to the type of provided services, where diffusion (broadcast) seems useful in ITS services including safety-related messages’ transfer. As well, different transmission priorities could exist according to the services type. Security is an important technical challenge, having an impact on the deployment of vehicular networks. In this context, trust among the communicating parties (whether vehicles or infrastructure elements) should be guaranteed, only authorized users should be able to participate in the vehicular communication and to access the offered services, and secure data transfer should be achieved. We notice that the requirements vary according to the type of services. This paper discusses from a deployment perspective some important issues for vehicular networks deployment. Section 2 presents some possible deployment architectures and discusses some promising wireless technologies. Vehicular networks security is discussed in Section 3, illustrating the possible attacks in such environment, the different security requirements and the problem of authentication, authorization and access control. Section 4 gives an overview of two security contributions in urban and city vehicular environments. Finally, we conclude the paper in Section 5.
technology as well as the new ad hoc scenarios defined within the IETF [7, 8], allow several possible vehicular networks architectures. Diverse wireless technologies are expected to take place in these networks comprising homogenous communication and heterogeneous communication. The former allows vehicular communication between similar wireless technologies; while in the latter communication between different wireless technologies can take place (e.g. Communication between 802.11 and UMTS). 2.1 Possible Architectures
Generally, there are three alternatives in deploying vehicular networks, as follows: i) a pure wireless Vehicle-to-Vehicle ad hoc network (V2V) allowing standalone vehicular communication with no infrastructure support, ii) a permanent Vehicle-toRoad (V2R) architecture constituting of a wired backbone with wireless last hops and requiring permanent connectivity with the fixed infrastructure (e.g. classical WLAN scenarios), iii) and an intermittent Vehicle-to-Road (V2R) architecture that does not rely on a fixed infrastructure in a constant manner, but can exploit it for improved performance and service access when it is available (single and multi-hop communication could take place). Figure 1, illustrates these three alternatives.
V2V Architecture
Fixed Infrastructure
Permanent V2R Architecture
Fixed Infrastructure
2
ARCHITECTURES TECHNOLOGIES
AND
WIRELESS
Intermittent V2R Architecture
Vehicular networks can be provided by network operators, service providers or through integration between operators, providers and a governmental authority. This could take place in Urban, rural, and city environments. The recent advances in wireless
Figure 1: Different Deployment Architectures Views.
UbiCC Journal – Volume 3
23
In addition, the Car-to-Car Communication Consortium (C2C-CC) specified some architectural considerations for vehicular networks deployment [9], including: i) Road-Side Units (RSUs) existing along the road, and ii) vehicle equipment with an On Board Unit (OBU), and potentially multiple Application Units (AUs) executing a single or a set of applications while using the OBU communication capabilities. Vehicles’ OBUs and RSUs can form ad hoc networks, where communication can be: i) V2V taking place directly between OBUs via multi-hop or single-hop without involving any RSU, or ii) Vehicle-to-Infrastructure (V2I), in which OBUs communicate with RSUs in order to connect to the infrastructure. This is illustrated in Figure 2.
From a standard adaptation view, Software Defined Radio (SDR) benefits from today's high processing power to develop multi-band, multistandard base stations and terminals [12]. In fact, SDR technology is promising to operator in terms of increasing network capacity and simplifying network reconfiguration at the same time. Network operators are expected to provide an umbrella coverage integrating several standards with a real-time tradeoff to offer the users the best possible service.
3
SECURITY
Fixed Infrastructure
RSU
RSU
OBU
OBU
AU
AU
OBU
OBU
AU
AU
Figure 2: C2C-CC Architectures View.
2.2
Wireless Technologies
IEEE 802.11p Wireless Access in the Vehicular Environment (WAVE) standard is being developed, enhancing 802.11in order to support ITS applications [10]. This includes data exchange between highspeed vehicles and between the vehicles and the roadside infrastructure in the licensed ITS band of 5.9 GHz (5.85-5.925 GHz). IEEE 802.11p will be used as the groundwork for DSRC (Dedicated Short Range Communications), which is specifically designed for automotive use and is meant to be a complement to cellular communications by providing very high data transfer rates. On the other hand, IEEE 802.16a introduces the mesh mode enabling multi-hop communication, for broad radio coverage, operating in the licensed and unlicensed lower frequencies of 2-11 GHz and covering up to 50 km. However, 802.16a limitation concerns its target on the fixed broadband applications. IEEE 802.16e [11] is developed as an amendment to 802.16a to support subscriber stations moving at vehicular speeds. Its target is to conceive a system for combined fixed and mobile broadband wireless access, operating in the 2-6 GHz licensed bands.
Vehicular communication security is a major challenge, having a great impact on future deployment and applications of vehicular networks. Suitable security mechanisms should be in place providing authentication, access control, trust and secure communication between vehicles. In the context of vehicular communication security, one should separate between two terms: Safety and Security. Safety rather concerns peoples’ safety on roads including drivers and passengers; while security concerns the secure data transfer. Consequently, securing Inter-Vehicular Communication (IVC) should take into account both Safety and Security. Intelligent traffic can partially assure Safety through minimizing accidents’ possibility, warning people in case of dangers (as for example, when passing the speed limit or when approaching near foggy or snowy roads), and allowing collaborative driving. Nevertheless, the non secure data transfer has an impact on peoples’ safety even when intelligent traffic is in place. One can conclude that peoples’ safety and secure data transfer are two faces for the same coin, which is vehicular communication security. For providing vehicular communication security, robust and distributed security mechanisms should exist. These mechanisms should adapt to any vehicular environment and any type of application including whether ITS applications or other passengers oriented non-ITS applications. 3.1 Attacks Against Vehicular Communication
In fact, vehicular networks special characteristics make them susceptible to a wide range of attacks. The most common attacks are: impersonation, bogus information injection, non integrity, non confidentiality, and Denial of Service (DoS). Two classes of attacks are likely to occur in vehicular networks [13]: i) external attacks, in which attackers not belonging to the network jam the communication or inject erroneous information. ii) Internal attacks, in which attackers are internal compromised nodes that are difficult to be detected. Both types of attacks may
UbiCC Journal – Volume 3
24
be either passive intending to steal information and to eavesdrop on the communication within the network, or active modifying and injecting packets to the network [14]. As a counter-measure against most of these attacks, the following security considerations should be satisfied: i) providing a trust infrastructure between communicating vehicles, ii) mutual authentication between each communicating pair (whether two vehicles or a vehicle and a fixed element of the infrastructure), iii) efficient access control mechanisms allowing not only the authorization to the network access but also the authorization to the services’ access, and iv) confidential and secure data transfer. 3.2 Vehicular Communication Requirements Security
what one is sending, iii) which site one is accessing or which application one is using, and iv) where is the mobile client now (his location) and where is he going to be after a while. 3.3 Authentication, Authorization and Access Control
Since ITS applications are mainly targeting peoples’ safety on roads, while passengers oriented non-ITS applications are mostly concerned with commercial services provision on roads, thus securing inter vehicular communication is different in both cases. As a consequence, security requirements are different for each application type [2]. In fact, source authentication is a major requirement for ITS applications to achieve the main ITS purpose which is accidents’ avoidance. Source authentication can assure the legitimate safetyrelated messages transfer on one hand and gives every vehicle the right to receive safety-related messages on the other hand. Another important requirement concerns the time-sensitivity during safety-related messages transfer, where [15] states that the critical transmission delay for these messages is about 100ms. On the other hand, passengers’ oriented non-ITS applications necessitate more security requirements, as for instance mutual authentication between each two communicating parties, confidential data transfer, efficient authorization for services’ access. For both types of applications, we find that the nonrepudiation, the integrity and the non-traceability are important security requirements that worth considerations. Although traceability is a legitimate process for some governmental authorities and networks operators, the non-traceability is an important security requirement in order to assure peoples’ privacy. Thus a complex problem arises in this issue. In fact, a tough requirement in vehicular networks environments is to manage traceability in terms of allowing this process for the concerned authorities and at the same time assuring the nontraceability between mobile clients (vehicles) themselves. Nevertheless, the latter is difficult to be achieved and so far no promising solutions exist to resolve this issue in the vehicular networks dynamic and open environment. It is noticed that the word traceability can include: i) who is talking to who, ii)
Authentication and authorization are important counter-attack measures in vehicular networks deployment, allowing only authorized mobile nodes to be connected and preventing adversaries to sneak into the network disrupting the normal operation or service provision. A simple solution to carryout authentication in such environment is to employ an authentication key shared by all nodes in the network. Although this mechanism is considered as a plug and play solution and does not require the communication with centralized network entities, it is limited to closed scenarios of small number of vehicles, mostly belonging to the same provider. For wide scale commercial deployment of vehicular networks, the shared secret authentication has two main pitfalls: firstly, an attacker only needs to compromise one node (vehicle) to break the security of the system and paralyze the entire network. Secondly, mobile nodes (vehicles) do not usually belong to the same community, which leads to a difficulty in installing/pre-configuring the shared keys. In fact, distributed authentication and authorization schemes with secure key management are required in such environment. A possible approach for distributed authentication is the continuous discovery and mutual authentication between neighbors, whether they are moving vehicles or fixed architectural elements (e.g. access points or base stations). Nevertheless, if mobile nodes (vehicles) move back to the range of previous authenticated neighbors or fixed nodes, it is necessary to perform re-authentication in order to prevent an adversary from taking advantage of the gap between the last association and the current association with the old neighbor to launch an impersonation attack. The re-authentication procedure should be secure and with the minimum possible delay in order to assure services’ continuity.
4
SECURITY CONTRIBUTIONS FOR URBAN AND CITY ENVIRONMENTS
This section discusses two contributions in securing vehicular communication mainly concerning hybrid wireless networks, employing ad hoc networks in a connected as well as a standalone manner, allowing V2V and V2R communication. Consequently, vehicles can communicate to each
UbiCC Journal – Volume 3
25
other in an ad hoc manner and can connect to the infrastructure either directly or through a multi-hop fashion. These contributions particularly study security architectures as well as the problematic of Authentication, Authorization and Accounting (AAA) in vehicular networks environments. Security architectures and mechanisms have been proposed, aiming at providing secure communication while reducing the cost of the access to the infrastructure.
4.1
Inter-Vehicular Highways
Communication
On
The work in [16, 17] provides a secure architecture for inter-vehicular communication in Urban, environments. This architecture provides authentication and access control for mobile clients (vehicles) on highways, through proposing an integrated solution considering the service provider as the core entity for all authentication and access control operations. A novel authentication, authorization, and access control mechanism is developed to authenticate mobile clients with respect to service providers authorizing them to services' access, and also to ensure confidential data transfer between each communicating parties.
Ad hoc chain
Entry Point
Gas station
1
3
4
5
Access Network Backbone
As illustrated in Figure 3, the proposed solution employs Kerberos authentication model which provides both authentication and authorization to different services' access. The 802.11i standard is adapted to the vehicular environment setting up secure layer 2 links and guaranteeing confidential data transfer. The potential services considered in this work include vehicles’ Internet access, safety messages diffusion and inter-vehicles’ data transfer. The service provider is considered as the core entity for the authentication, authorization and access control process, where 802.11i authentication using EAP-Kerberos takes place at the entry point of highways (step1). Each client (vehicle entering the highway) communicates with the Kerberos authentication server, in this case, to carryout the authentication. This allows mutual authentication between each client in his vehicle and the service provider. Kerberos authentication model allows not only the authorization for the channel access but also the authorization for other services’ access. We consider two potential services here (that could be authorized through Kerberos service authorization tickets): IP address configuration and public certificates assignment. In (step 2) the authenticated client communicates with the TGS (Ticket Granting Server) to obtain two service authorization tickets respectively for the IP configuration and the public key certificate assignment. The client then presents the first obtained service ticket to a DHCP server (step 4) to obtain an IP address, and presents the second obtained service ticket to a certificate authority (step5) to obtain a public key certificate which will be used for later authentication with other vehicles during the trip. Mutual authentication is assured between each two communicating vehicles during the trip in a distributed manner, through adapting 802.11i authentication to the ad hoc mode (without needing to communicate with the authentication server “as the case of ‘step1’ at the entry point). However, EAP-TLS is employed making use of the previously obtained certificates. 802.11i authentication also guarantees confidential communication on each link between authenticated nodes, thanks to the encryption key generation. To achieve a reliable transfer, a routing approach is proposed adapting the Optimized Link State Routing (OLSR) protocol that is expected to provide a reliable routing infrastructure in such a hybrid scalable wireless environment, through introducing the concept of clustering to minimize the flooding effect of OLSR. A security analysis carried out for this work shows that minimizing the load on the authentication server in this work succeeds in reducing the authentication delay imposed by layer 2. Moreover, applying 802.11i in ad hoc mode ensures continuous authentication for communication parties and secure links setup while avoiding the shared
CA
Authentication TGS Server
DHCP Server
DB
KDC
2
Figure 3: Proposed Architecture and Security Solution on Highways.
UbiCC Journal – Volume 3
26
secret weakness of the PSK (Pre-Shared Key) authentication proposed by the standard for ad hoc mode. 4.2 Providing A Trust Infrastructure, Authentication, Access control and Secure Data Transfer
The work in [2] addresses the security in vehicular communication general city environments, aiming to propose innovative solutions for deploying vehicular networks in such environments and allowing secure communication between participants. To enhance vehicular networks ubiquitous secure access, a novel architecture and security mechanisms are proposed taking advantages of: i) the ad hoc multi-hop authentication concept, ii) the smart cardbased authentication allowing distributed authentication during V2R communication, and iii) the wireless grid paradigm for distributed authentication and resources' aggregation among mobile vehicles.
respect to the network operator or the service provider and hence authorized to services’ access. To allow the authentication of vehicles not having a direct communication with the access network, mobile vehicles themselves are used as relays to transfer authentication messages of those far-away vehicles. Another option is to carryout an off-line authentication before participating to the vehicular network. This is achieved through employing smart cards, storing legitimate clients credentials and allowing authentication of these clients preceding their participation to the vehicular network. The second step is allowing authentication and secure communication between communicating vehicles themselves. This takes place based on credentials obtained after each successful authentication with the authentication server, using a distributed certificatebased approach. To enhance the authentication performance, the wireless grid concept is used for sharing authentication credentials among some authorized elements in the security architecture, which could save a considerable authentication delay. Actually, the wireless grid approach can be extended to mobile vehicles themselves. EAP authentication model is used, while being general to any underlying wireless technology. The multi-hop EAP messages exchange is assured through a stateless hop-by-hop relaying mechanism, functioning on top of layer2. Consequently, there is no need of employing a routing protocol for accomplishing the authentication and secure links setup process, thus saving the overhead of routing tables’ storage and maintenance in such highly dynamic environment. The proposed security mechanisms allow mutual authentication between communicating vehicles, massages’ source authentication, non repudiation, and fast association and reconnect. A security analysis for the developed mechanisms shows its efficiency and robustness towards some critical attacks while supporting high mobility as well as time-sensitive applications.
5
CONCLUSION AND OUTLOOK
Figure 4: Security Architecture for Inter-vehicular Communication In City Environment.
As shown in Figure 4, a hybrid ad hoc network approach is employed to extend the access network coverage on one hand and to allow far away nodes (moving vehicles) to communicate to the authentication server (sitting in the operator backbone network) on the other hand. As a first step, each moving vehicle, whether being in the access network coverage or not, can get authenticated with
This paper presents some deployment perspectives for vehicular networks, illustrating deployment architectures examples together with some promising wireless technologies. Vehicular communication security is addressed, presenting some important security requirements. The problem of authentication, authorization and access control in these networks is discussed and a couple of related contributions in this subject are also presented. We notice that vehicular networks are promising in being one of the real applications of ad hoc networks; however a number of technical challenges
UbiCC Journal – Volume 3
27
can slow their development and can impact their wide-scale deployment. Security is one of the significant challenges impacting vehicular networks. A point that complicates this issue is that securing vehicular communication is service-related. For instance, safety-related services should be granted to every vehicle on the road while assuring the secure messages’ transfer. On the other hand, from a commercial deployment perspective, only authorized mobile nodes (vehicles) should be granted network's access and hence services’ access. Since vehicular networks can be managed by more than one operator/provider, authentication should be performed during mobile nodes’ (vehicles) roaming not only across different BSs or APs but also across different administrative domains. This also necessitates trust relationships among the stakeholders for authentication, authorization, accounting and billing of end users. Moreover, traceability versus privacy is an important point that needs efficient management. Efficient mechanisms and systems should be in place to allow moving vehicles traceability only by legitimate authorities, while protecting their privacy with respect to other vehicles and at the same time preventing privacy disclosure attacks.
Architecture: WLAN-based Internet Access on the Road, IEEE VTC, 2004. [7] I. Chakeres, J. Mackers, T. Clausen: Mobile Ad hoc Network Architecture, I-D draft-ietf-autoconfmanetarch-06, October 2007 (work in progress). [8] E. Bacelli, K. Mase, S. Ruffino, S. Singh: Address Autoconfiguration for MANET: Terminology and Problem Statement, I-D draft-ietfautoconf-statement-01, August 2007 (work in progress). [9] Car2Car Communication Consortium Manifesto, work in progress, May 2007. [10] IEEE P802.11p: Draft Amendment to STANDARD FOR Information technology— Telecommunications and information exchange between systems—LAN/MAN Specific Requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: Wireless Access in Vehicular Environments (WAVE). [11] IEEE Standard for Local and metropolitan area networks Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems Amendment 2: Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands and Corrigendum 1, February 2006. [12] M. Uhm: Making the Adaptivity of SDR and Cognitive Radio Affordable, DSP Magazine, May 2006. [13] L. Zhou, Z. Haas: Securing Ad hoc Networks, IEEE Network Magazine, 13(6):24-30, 1999. [14] M. Raya, J. P. Hubaux: The Security of Vehicular Networks, ACM Workshop on Security of Ad hoc and Sensor Networks, SASN05, 2005. [15] X. Yang, J. Liu, F. Zhao, N. Vaidya: A vehicleto-vehicle communication protocol for cooperative collision warning, MobiQuitous, August 2004. [16] H. Moustafa, G. Bourdon, Y. Gourhant: AAA in Vehicular Communication on highways using Ad hoc Network Support: a proposed Architecture, Proceedings of the second ACM workshop on VANETs 2005, in conjunction with MobiCom 2005, September 2005. [17] H. Moustafa, G. Bourdon, Y. Gourhant: Providing Authentication and Access Control in a Vehicular Network Environment, IFIP SEC 06, 2006.
6
REFERENCES
[1] H. Hartenstein, B. Bochow, A. Ebner, M. Lott, M. Radimirsch, D. Vollmer: Position-Aware Ad Hoc Wireless Networks for Inter-vehicle Communications: The Fleetnet Project, ACM Symposium on Mobile Ad Hoc Networking and Computing, MobiHoc, 2001. [2] C. Tchepnda, H. Moustafa, H. Labiod, G. Bourdon: Securing Vehicular Communications: An Architectural Solution Providing a Trust Infrastructure, Authentication, Access Control and Secure Data Transfer, ACM Autonet 2006 workshop in conjunction with Globecom 2006. [3] J. P. Hubeaux, S. Capkun, J. Luo: The Security and Privacy of Smart Vehicles, IEEE Computer Society, 2004. [4] P. Golle, D. Greene, J. Staddon: Detecting and Correcting Malicious Data in VANETs, ACM VANET, October 2004. [5] M. Raya, J. P. Hubaux: The Security of Vehicular Ad Hoc Networks, ACM SASAN, 2005. [6] J. Ott, D. Kutscher: The “Drive-thru”
UbiCC Journal – Volume 3
28
Current Trends in Vehicular Ad Hoc Networks
Ghassan M. T. Abdalla*, Mosa Ali AbuRgheff* and Sidi Mohammed Senouci** *University of Plymouth – School of Computing, Communications & Electronics, UK **France Télécom — Recherche et Développement CORE, France Email: ghassan.abdalla@plymouth.ac.uk
ABSTRACT Vehicular Networks are receiving a lot of attention due to the wide variety of services they can provide. Their applications range from safety and crash avoidance to Internet access and multimedia. A lot of work and research around the globe is being conducted to define the standards for vehicular communications. These include frequency allocation, standards for physical and link layers, routing algorithms, as well as security issues and new applications. In this paper we review the standardization work and researches related to vehicular networks and discuss the challenges facing future vehicular networks. Keywords-- DSRC, IEEE 802.11, MAC, Routing, Security, UTRATDD, Vehicular communications, WAVE.
1. Introduction illions of people around the world die every year in car accidents and many more are injured. Implementations of safety information such as speed limits and road conditions are used in many parts of the world but still more work is required. Vehicular Ad Hoc Networks (VANET) should, upon implementation, collect and distribute safety information to massively reduce the number of accidents by warning drivers about the danger before they actually face it. Such networks comprise of sensors and On Board Units (OBU) installed in the car as well as Road Side Units (RSU). The data collected from the sensors on the vehicles can be displayed to the driver, sent to the RSU or even broadcasted to other vehicles depending on its nature and importance. The RSU distributes this data, along with data from road sensors, weather centres, traffic control centres, etc to the vehicles and also provides commercial services such as parking space booking, Internet access and gas payment. The network makes extensive use of wireless communications to achieve its goals but although wireless communications reached a level of maturity, a lot more is required to implement such a complex system. Most available wireless systems rely on a basestation for synchronization and other services; however using this approach means covering all roads with such infrastructure which is impractically too expensive. Ad hoc networks have been studied for some time but VANET will form the biggest ad hoc network ever implemented, therefore issues of stability, reliability and scalability are of concern. VANET therefore is not an architectural network and not an ad hoc network but a combination of both; this
M
unique characteristic combined with high speed nodes complicates the design of the network. In this paper we provide an overview of the technologies and ongoing research related to VANET. The history and the first generation VANET systems around the world are reviewed in the next section. Current frequency allocation and physical layer standards are presented in section three. In section four the IEEE WAVE standards for vehicular communications are discussed. The fifth part presents the link layer followed by a review of the routing and broadcasting algorithms designed for VANET in section six. An overview of VANET applications is provided in section seven along with some current prototypes of these applications. A discussion about security issues followed by open research problems are presented in sections eight and nine, and then finally the paper is concluded. 2. Background of Vehicular Communications The original motives behind vehicular communications were safety on the road, many lives were lost and much more injuries have been incurred due to car crashes. A driver realising the brake lights of the car in front of him has only a few seconds to respond, and even if he has responded in time cars behind him could crash since they are unaware of what is going at the front. This has motivated one of the first applications for vehicular communications, namely cooperative collision warning which uses vehicle to vehicle communication [1]. Other safety applications soon emerged as well as applications for more efficient use of the transportation network, less congestion and faster and safer routes for drivers. These applications
UbiCC Journal – Volume 3 29
cannot function efficiently using only vehicle to vehicle communications therefore an infrastructure is needed in the form of RSU. Although safety applications are important for governments to allocate frequencies for vehicular communications, nonsafety applications are as important for Intelligent Transportation Systems (ITS) for three reasons [2]: 1) ITS systems rely on essential equipment which should be installed in every car and is widely available to the users. However, it is unlikely that individuals can afford such expensive equipment. 2) Safety applications generally require limited bandwidth for short intervals of time. Since bandwidth efficiency is an important factor, nonsafety applications are important to increase bandwidth efficiency. 3) The availability of RSU provides an infrastructure which can be used to provide a lot of services with only a little increase in cost. Besides road safety, new applications are proposed for vehicular networks, among these are Electronic Toll Collection (ETC), car to home communications, travel and tourism information distribution, multimedia and game applications just to name a few. However these applications need reliable communication equipment which is capable of achieving high data rates and stable connectivity between the transmitter and the receiver under high mobility conditions and different surroundings. Different frequencies for VANET were allocated in different parts of the world. In North America the Dedicated Short Range Communications (DSRC) band 902928 MHz was allocated. It provided short range communications (<30m) and low data rates (500 kbps). It is still used for some types of electronic toll collection systems but its performance is too limited to satisfy the demanding requirements of ITS applications. In Japan the bands 58355840 and 5845 5850 MHz were allocated for uplink and 5790 5795 and 58005805 MHz for downlink for the Association of Radio Industries and Businesses standard ARIB STDT55. The system relies on road architecture, as with DSRC, and provides ETC service. The standard uses ASK modulation for a data rate of 1Mbps with 8 slot TDMA/FDD to provide service for a maximum of 8 cars within a range of 30m. Currently a new standard (ARIB STDT75) is being developed [3]. These systems can be regarded as the first generation for vehicular communications. The different standards and frequencies hindered the implementation of ITS systems since each country has its own specifications and operating systems. Moreover the low data rates and short
distances were only suitable for a limited number of applications. 3. Physical Layer In 1999 the Federal Communications Commission (FCC) allocated a new 75 MHz band DSRC at the 5.9 GHz frequency for ITS applications in North America. The band is divided into 7 channels as shown in Fig. (1) [4]. A physical layer standard is being developed by the American Society for Testing and Material (ASTM) known as standard ASTM E2213. It uses Orthogonal Frequency Division Multiplexing (OFDM) as its modulation scheme and adopts IEEE 802.11a for the link layer. The standard covers distances up to 1 km [5].
Optional 20MHz Control
Ch Ch Ch Ch Ch Ch Ch 172 174 176 178 180 182 184 5.850 5.855 5.865 5.875 5.885 5.895 5.905 5.915 5.925
Optional 20MHz
GHz
Fig (1): DSRC bands in North America. OFDM is a multicarrier modulation scheme. Data is split into multiple lower rate streams and each stream is used to modulate one of the subcarriers. Since the data rate is reduced, lower bandwidth is required for each carrier. The carriers are spaced at intervals of 1/T, where T is the symbol duration; therefore they are orthogonal to each other. Although high data rates can be achieved using OFDM, the performance of OFDM can degrade rapidly if careful considerations for synchronization and channel variations are not taken. OFDM is sensitive to frequency and phase errors [6, 7]. Because the subcarriers are very close to each other, any drift in the frequency causes Inter Carrier Interference (ICI). In VANET the high relative speeds between vehicles on opposite sides or between the vehicle and the RSU cause an increase in the received frequency as the vehicles move towards each other and a decrease as vehicles move away due to the Doppler effect. This must be taken into account during the design of the receiver as it destroys the orthogonality of the carriers and increases ICI [8]. Reliable communications is an important issue in VANET and fading is a well known limitation in all wireless links. However The effects of fading can be reduced by using diversity techniques in VANET. Diversity techniques have been examined extensively in wireless communications, but due to the limited space in mobile terminals they are only used in basestations. Space is not an issue in VANET
UbiCC Journal – Volume 3 30
and therefore using multiple antennas is a reasonable solution for reliable communications. Fig (2) shows a bit error rate (BER) comparison between single antenna and multiple antenna receivers using maximal ratio combining (MRC) [9].
10
0
maximum data rate of 2 Mbps for still nodes and 384kbps for mobile nodes [3].
10
0
BER vs EbNo
60 km/hr 100 km/hr 180 km/hr
10
1
BER vs SNR
10
1
1 antenna 2 antennas 3 antennas 4 antennas
BER
10
2
10
2
10
BER
3
10
3
10
4
4
10
0
1
2
3
4
10
5
5 EbNo (dB)
6
7
8
9
10
10
6
th Fig (3): BER performance with 4 order diversity and different speeds.
2
10
7
0
4
6
8
12 10 SNR(dB)
14
16
18
20
Part 2
Non safety related
Road safety and traffic efficie ncy IVC and R2V Focus on R2V
5.850
Part 1
Critical road safety IVC and R2V Focus on IVC
Part 2
Road safety and traffic efficiency IVC and R2V Focus on R2V
Fig (2): BER performance with diversity. IEEE 802.11a standard uses 64 carriers, 48 are dedicated for data, 4 are pilot carriers and the other carriers are not used to reduce interference to other bands. Training sequences are used at the beginning of the packet for training and the pilot carriers channel response is extrapolated to estimate the channel response for the other carriers [10]. This scheme performed well with WLAN since the terminals had limited mobility, however with VANET the terminals can move in speeds of 100 km/hr or more. To illustrate this consider two cars moving in opposite directions each with speed of 150 km/hr. At 5.9 GHz this results in a Doppler Shift of 1.6 kHz, yielding a channel coherence time of 300 ms. The maximum length of an IEEE 802.11 packet is 18768 bits and at 54 Mbps this takes 348 ms to be transmitted. Note that 54 Mbps is the maximum data rate, if the nodes are using a lower data rate (e.g. 6 Mbps) this will take much longer. Therefore the training sequence at the start of the frame will lose its significance at the end of the packet and whether the 4 pilot carriers are significant to estimate the channel or not is a matter of concern. Fig (3) shows the effect of speed in channel estimation using training sequence and a MRC receiver with four antennas. In Europe a spectrum aligned with the DSRC spectrum in North America is being considered as shown in Fig (4) [11]. The band 5.885 to 5.905 GHz in the form of two 10 MHz channels is expected to be allocated first followed by the rest of the spectrum [12]. The adaptation of UTRATDD for VANET communications was studied in the FleetNet project but this is still an open area and some projects adapt IEEE 802.11 for their studies. UTRATDD standard, however, can provide a
IVC and R2V
Control Channel
5.865 5.875
5.885 5.895 5.905 5.915 5.925 GHz
Fig (4): Frequency Proposal in Europe. In Japan the new ARIB STDT75 standard uses 14, 4.4 MHz channels, 7 for downlink and 7 for uplink as shown in Fig (5). The standard uses ASK to provide a data rate of 1Mbps and QPSK to provide 1 or 4 Mbps. It also makes use of 8 slots TDMA/FDD to provide service to a maximum of 56 cars within a range of 30m. The system provides ETC service as well as information shower [3]. For InterVehicle Communication (IVC) cars need to communicate in an ad hoc manner. Since no infrastructure is present, cars in the road form a temporary group in order to use the standard to exchange information.
4.4MHz
Downlink
5.775 5.780 5.785 5.790 5.795 5.800 5.805 5.810 GHz
Uplink
5.810 5.815 5.820 5.825 5.830 5.835 5.840 5.845 GHz
Fig (5): ARIB STDT75 frequencies.
UbiCC Journal – Volume 3 31
4. IEEE Standards While ASTM E2213 standard is being developed, the IEEE standards IEEE P1609.1, P1609.2, P1609.3 and P1609.4 were prepared for vehicular networks. P 1609.3 is still under further development but the other three were recently released for trial use. P1609.1 is the standard for Wireless Access for Vehicular Environment (WAVE) Resource Manager. It defines the services and interfaces of the WAVE resource manager application as well as the message and data formats. It provides access for applications to the rest of the architecture. P1609.2 defines security, secure message formatting, processing, and message exchange. P1609.3 defines routing and transport services. It provides an alternative for IPv6. It also defines the management information base for the protocol stack. P1609.4 covers mainly how the multiple channels specified in the DSRC standard should be used. The WAVE stack uses a modified version of IEEE 802.11a for its Medium Access Control (MAC) known as IEEE 802.11p [13, 14]. The protocol architecture defined by IEEE is shown in Fig (6) and the WAVE standards in Fig (7) [14].
Applications
Management Plane
Data Plane
WME
UDP IPv6
WAVE Short Message
Logic Link Control
MLME Medium Access Control PLME
Physical
Medium
Fig (6): IEEE architecture
P1609.1 and others P1609.3 P1609.4 802.11p
Upper Layers
Networking Services
WAVE Security
Lower Layers
Medium
5. Link Layer The IEEE 802.11p standard is still under development. The draft specifies data rates from 3 to 27 Mbps for 10 MHz channels and 6 to 54 Mbps for 20 MHz channels. Nodes communicate with each other in an ad hoc fashion known as Wireless Access for Vehicular Environment (WAVE) mode. RSU form a Basic Service Set with the vehicles, known as WAVE BSS (WBSS) in order to communicate. RSU sends WBSS announcement frames and vehicles can optionally join the WBSS. Authentication and association routines are not performed in WBSS and the Point Coordination Function (PCF) will not be used in this standard. Data priorities are handled using Enhanced Distributed Channel Access (EDCA) as defined in the IEEE 802.11e standard. The protocol can operate in the European and Japanese frequencies [13, 15]. The use of Request To Send/Clear To Send (RTS/CTS) packets and windows in IEEE 802.11p does not solve the hidden/exposed terminals in the adhoc VehicletoVehicle (V2V) communications mode due to the high mobility of the terminals. A packet between two stationary, or slowly moving, vehicles passing all the Distributed Coordination Function (DCF) constraints can still collide with another packet sent from a fast moving (or in the opposite lane) vehicle unaware of the RTS/CTS handshake. This scenario can occur rapidly in V2V networks causing very low throughput. In Europe the FleetNet project studied the extension of the UTRATDD standard for decentralised vehicular networks. An adhoc mode of UTRATDD known as Opportunity Driven Multiple Access (ODMA) can provide access to approximately five nodes within coverage range but relies on a basestation for synchronization. Since a basestation is not always available to provide synchronization, a new adhoc proposal based on UTRATDD was introduced [16]. The new modified UTRATDD achieves synchronization in two steps, first using GPS to achieve coarse synchronization between nodes, then using a midample to achieve fine synchronization [17, 18]. The standard uses TDMA slots with 16 CDMA codes for every slot. Reserve slots are used by the nodes to reserve a slot prior to communication while high priority data are transmitted via separate dedicated slots [19]. Simulations showed that the modified UTRATDD outperformed the IEEE 802.11b [20]. The proposed access mode was extended afterwards to work with several frequencies [21]. 6. Routing Algorithms Routing has always been a challenge in mobile ad hoc networks (MANET) since the positions of the nodes change with time. Existing
P1609.2
Fig (7): WAVE standards
UbiCC Journal – Volume 3 32
solutions were generally optimised for slow movement and their design was constraint by the power consumption and/or the processing capabilities of the nodes. Such constraints are not essential in VANET. Moreover the movement in VANET is constraint by the road and highly predictable which is not the case in MANET where the mobility is random and in two dimensions. Broadcasting and routing algorithms for VANET were studied in FleetNet project. Their focus was on using the positioning information provided by GPS for routing and broadcasting. Three routing protocols were considered, Position Based Forwarding (PBF), Contention Based Forwarding (CBF) and Ad hoc On Demand Distance Vector (AODV). All these protocols are reactive protocols. Reactive protocols discover the route to a destination only when a message is to be delivered counter to proactive protocols which tend to store routing tables for every destination and update these routing tables continuously. As the topology of VANET changes frequently, the signalling messages of proactive protocols can result in a large overhead load. PBF and CBF use location service algorithms to find the position of the destination, based on this position PBF selects one of the surrounding nodes to forward the message. This process is repeated till the message reaches it destination. In CBF the source transmits the message with the position of the destination; every node receiving the message sets a timer proportional to the difference between its position and the destination. If the timer expires and no other node has broadcasted the message, the node forwards the message to the destination. In AODV the source floods the network with a route request for the destination. Nodes receiving the request calculate a distance vector and forward the message, this process is repeated till the destination is reached which sends a route reply. Once the reply is received the route is ready for sending the data. To reduce the flooding effects maximum hop count and Time To Live (TTL) fields are used in route messages. Simulations show that CBF performs better than the other algorithms and it adapts to changes in the topology which interrupt routes in the other two protocols. CBF, however, requires the assistance of maps in cities when multiple roads intersect and run in parallel, its performance in congested areas also requires more investigation since several cars might have the same distance to the destination which might cause collisions [22, 23]. A broadcasting algorithm based on CBF has also been suggested for safety applications. A car encountering an accident broadcasts a safety message and its current position. Other cars receiving this
message set a retransmission timer inversely proportional to their distance from the source and rebroadcast the message if no other node broadcasts first and keeps rebroadcasting till it receives a message from another node or the message is no longer relevant [24]. Another routing algorithm known as Greedy Traffic Aware Routing (GyTAR) has also been proposed in [25]. The algorithm targets the routing problem in cities. It works with the aid of maps and traffic density information to calculate the best direction in junctions the packet should take to reach its destination. The calculation is based on the distance, number of cars within that distance, their movement and speed. The paper also proposed a system for collecting and distributing information about the road and traffic conditions which can be used with GyTAR as well as other algorithms. Although these algorithms, and others, provide a solution to the routing problem in VANET, still more research is required to examine their performance, applicability and overhead. A major issue of concern is the achievable throughput of the system. This has been examined in [26]. According to their results the throughput decreases considerably with the number of hops and can be as low as 20kbps in 2Mbps links with 6 hops. 7. Applications of VANET A large number of applications have been specified by governments for DSRC applications, we cover here a few of them. Traffic control is a major factor for efficient use of the network. Currently traffic lights organize the flow of traffic at junctions. With DSRC traffic lights become adaptive to the traffic and can provide priority to emergency vehicles as well as safety to pedestrians and cyclists. Moreover information about the status of the road can be distributed to cars to warn them of problems ahead such as ice or maintenance work on the road. This system will also be very efficient in the case of accidents, automatically notifying the nearest ambulance and other emergency vehicles to approach the accident if needed and even provide telemedicine services if the patient requires immediate attention, especially when there are no nearby hospitals. Crash prevention is the main motive behind ITS, therefore a number of applications have been specified. Crash prevention applications that rely on an infrastructure include road geometry warning to help drivers at steep or curved roads and warn overweight or overheight vehicles, highwayrail crossing and intersection collision systems to help drivers cross safely, pedestrian, cyclist and animal warning systems to inform drivers of possible collisions, these
UbiCC Journal – Volume 3 33
systems become of vital importance at night or under low visibility conditions [1]. Safety applications which do not rely on an infrastructure include an emergency brake announcement which is the most important application for crash prevention. The first two cars might not benefit from the emergency brake system but further cars can avoid the crash. Lane change assistance, road obstacle detection, road departure warning as well as forward and rear collision warning are all examples of safety V2V applications. Vehicles can also automatically send help requests in case of an accident which can be vital when no other cars are around [1]. An ongoing European project, eCall, aims at providing this automatic call service by 2009 using existing cellular infrastructure [27]. The OBU system can also help the driver in other different ways such as vision enhancement via image processing techniques, lane keeping assistance and monitoring of onboard systems as well as any cargo or trailers connected to the vehicle. Such systems are generalised as Advanced Driver Assistance Systems (ADAS) [27]. The commercial applications of the system cover a wide range of innovative ideas aiding individuals and tourists such as booking a parking place, downloading tourism information and maps for restaurants and gas stations, navigation and route guidance, payment at toll plazas, Internet access and connection to home computers. Other devices within the vehicle can also be connected to the On Board Units (OBU) to access any services provided by the network or through the Internet. These applications are not required by the government but they encourage people to install the system. A Japanese project called PDRGS (Dynamic Route Guidance System) is one possible implementation of the navigation and route service. This project is developing a system known as PRONAVI that currently consists of a server accessible through the Internet. Users enter their start position, destination and time to start their journey and the server responds with the best two routes. The routes are compiled from a 9 months survey as well as simulations. In its final version the system should be able to collect data from the sensors installed in cars and provide the routes to the OBU [28]. The Vehicle Information and Communication System (VICS) is another Japanese implementation of roadside to vehicle communications. Subscribers to the system get an onboard navigation system that receives information about the weather, road conditions, traffic and any other related data from road side units and displays it to the user [29].
In Europe the eSafety initiative was launched in April 2002. Currently it has 14 workgroups working in the areas of accident causation analysis, communications, digital maps, Emergency Call (eCall), heavy duty vehicles, HumanMachine Interaction (HMI), information and communication technologies for clean mobility, implementation road map, international cooperation, Realtime Traffic and Travel Information (RTTI), research and development, security, serviceoriented architectures and user outreach. The eSafety forum aims to accelerate the development, deployment and use of eSafety systems to reduce the number of fatalities in Europe to 50% by 2010 [27]. The CARLINK project was launched in 2006 by CELTIC EUREKA with realtime local weather information, the urban transport traffic management and the urban information broadcasting as the primary applications. It aims at integrating WLAN, WiMAX as well as cellular technology to provide the information to cars on the road as well as to PDAs and mobile phones [30]. 8. Security Issues The ongoing Network On Wheels (NOW) project addresses a number of issues in vehicular networks with a focus on security. The project adopts an IEEE 802.11 standard for wireless access and aim at implementing a reference system. The project addresses a number of security issues for VANET [31]. VANET security should satisfy four goals, it should ensure that the information received is correct (information authenticity), the source is who he claims to be (message integrity and source authentication), the node sending the message cannot be identified and tracked (privacy) and the system is robust. Several attacks can be identified and these can be generalized depending on the layer the attacker uses. At the physical and link layers the attacker can either disturb the system by jamming or overloading the channel with messages. Injecting false messages or re broadcasting an old message is another possible attack. The attacker can also steal or tamper with a car system or destroy a RSU. At the network layer the attacker can inject false routing messages or overload the system with routing messages. The attacker can also compromise the privacy of drivers by revealing and tracking the positions of the nodes. The same attacks can be achieved from the application layer [32]. In the IEEE WAVE standard vehicles can change their IP addresses and use random MAC addresses to achieve security [13]. Vehicles also keep the message exchange to a minimum at the start of the journey for some time so that the messages cannot be tied to the vehicle.
UbiCC Journal – Volume 3 34
A number of security algorithms have been developed in France Telecom R&D department. The security proposal provides security at the link layer for vehicle safety and commercial applications, higher layer security protocols can also be used to further enhance the security or provide end to end security in a multihop link. The proposal makes use of four types of certificates, two long term and two short term. One long term and one short term certificates are used for ITS services while the others are for nonITS applications. Long term certificates are used for authentication while short term certificates are used for data transmission using public/private key cryptography. Safety messages are not encrypted as they are intended for broadcasting, but their validity must be checked; therefore a source signs a message and sends it without encryption with its certificate, other nodes receiving the message validate it using the certificate and signature and may forward it without modification if it is a valid message. NonITS data can rely on higher layer protocols to provide endtoend security especially over a multihop link [33]. Another scheme has been proposed in [34]. The proposal suggests the use of a long term certificate, issued by a governmental authority (GA), and temporary certificates, issued by private authorities (PA), as well as pseudonyms to protect the privacy of the drivers. For commercial services, if the user is communicating directly with the RSU, its identity is validated via the long term certificate by the GA and then it is issued a temporary certificate and pseudonym by the PA to be able to use the service. For communications via hops the source signs the message using the long term certificate, forwarding vehicles verify the message and sign it using their own certificates and so on till it reaches the RSU. The rest of the processing is similar to the direct case. The obvious limitation of this proposal is the overhead and processing time required especially when several hops are needed to reach the RSU. 9. Open Research Areas Vehicular networks introduce a new challenging environment for communication engineers. The communication channel can vary from a simple point to point microwave link for cars in open areas, to rich Rayleigh fading within the cities. Moreover the channel varies considerably every few seconds and line of sight blockage occurs frequently. Therefore the physical layer commonly operates under various channel conditions and is expected to provide high data rates even though the communication time can be limited to a few seconds. Adaptive and efficient channel estimation algorithms are
needed, diversity techniques to overcome fading effects should be examined and Doppler effects should be carefully considered especially when using OFDM signalling. The link layer is expected to provide various delay needs and QoS classes to satisfy the different requirements of the applications. It should also organize the access to the medium and resolve collisions under high mobility conditions. The RTS/CTS mechanism of IEEE 802.11 will perform poorly in V2V communications because the nodes move very fast. UTRATDD provides a number of elegant solutions but how it will perform under different load conditions is a matter that requires further investigation. The maximum data rate for UTRA TDD is 2Mbps which is lower than the minimum data rate specified for IEEE 802.11p. Efficient broadcasting algorithms are essential for delivery of safety and routing messages. Routing protocols that rely on GPS were introduced in section 5. However these protocols still require further investigations and their throughput, stability and capability to work when few cars are on the road as well as in congested areas are of concern. IP version 6 has been proposed for use in vehicular networks. Cars should be able to change their IP addresses so that they are not traceable, however it is not clear how this will be achieved. Moreover this can cause inefficiency in address usage since when a new address is assigned the old address cannot be reused immediately. Delayed packets will be dropped when the car changes its IP address which causes unnecessary retransmissions. Vehicular networks rely on distributed untrustworthy nodes which should cooperate with each other and with RSU. Issues of security are a major concern for safety applications as well as for commercial applications. Any developed security solution should meet the diverse needs of the applications while taking into consideration the processing capabilities of the OBU. The network should also work with minimum human interaction since otherwise it will divert the driver’s attention from the road. Other related research areas of great importance include sensor design, antenna design, OBU specifications, driverOBU interface, RSU design, RSU to RSU communication network specifications and VANET servers’ requirements and software platform just to name a few. These systems should cooperate in an efficient manner to reach the ultimate goal of faster, safer and information rich journeys on the road. 10. Conclusion In this paper we have provided an overview of the development of the communication standards
UbiCC Journal – Volume 3 35
and ongoing research for vehicular networks. Frequencies have already been allocated in North America and Japan and are expected soon in Europe. The IEEE 802.11p and WAVE suite were recently released for trial use. Routing protocols, broadcasting algorithms and security algorithms are being developed for vehicular networks as well as safety and commercial applications. Vehicular networks will not only provide safety and life saving applications, but they will become a powerful communication tool for their users. Acknowledgement The authors would like to thank France Telecom and the University of Plymouth for supporting this work. References [1] "ITS Applications Overview," http://itsdeployment2.ed.ornl.gov/technology_ overview/. [2] K. Matheus, R. Morich, and A. Lübke, "Economic Background of CartoCar Communication," http://www.network–on– wheels.de/documents.html, 2004. [3] K. Tokuda, "DSRCType Communication System for Realizing Telematics Services," Oki Technical Review, vol. 71, No.2, pp. 64 67, April 2004. [4] L. Armstrong, "Dedicated Short Range Communications (DSRC) at 5.9 GHZ," Presentation, http://www.leearmstrong.com/DSRC%20Hom e/Standards%20Programs/North%20America n/DSRC%20Summary.ppt. [5] "American Society for Testing and Materials (ASTM)," www.astm.org. [6] M. C. D. Maddocks, "An Introduction to Digital Modulation and OFDM Techniques," BBC Research Department Report No RD 1993/10 1993. [7] J. A. Stott, "The Effects of Frequency Errors in OFDM," BBC Reseearch Department Report No RD 1995/15 1995. [8] T. Wang, J. G. Proakis, E. Masry, and J. R. Zeidler, "Performance Degradation of OFDM Systems Due to Doppler Spreading," IEEE Transactions On Wireless Communications, vol. 5, pp. 14221432, June 2006. [9] J. G. Proakis, Digital communications, 4th ed. Singapore: McGraw Hill, 2001. [10] B. O'Hara and A. Petrick, IEEE 802.11 Handbook A Designer's Companion. New York: Institute of Electrical and Electronics Engineers Inc., 1999. [11] S. Hess, "Frequency spectrum for ITS," COMeSafety July 2006. [12] "COMeSafety Forum," http://www.comesafety.org.
[13] "IEEE Draft P802.11p/D2.0, November 2006." [14] "IEEE Draft P1609.0/D01, February 2007." [15] "IEEE Draft P802.11p/D0.25, November 2005." [16] M. Lott, "Performance of a Medium Access Scheme for Intervehicle Communication," in Proc. of International Symposium on Performance Evaluation of Computer and Telecommunication Systems (SPECTS'02), San Diego, California, July 2002. [17] A. Ebner, H. Rohling, R. Halfmann, and M. Lott, "Synchronization in Ad Hoc Networks Based on UTRA TDD," in Proceedings of the 13th IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC 2002), Lisbon, Portugal, 2002. [18] A. Ebner, H. Rohling, M. Lott, and R. Halfmann, "Decentralized Slot Synchronization In Highly Dynamic Ad Hoc Networks," in Proceedings of the 5th International Symposium on Wireless Personal Multimedia Communications (WPMC'02), Honolulu, Hawaii, 2002. [19] M. Lott, "Performance of a Medium Access Scheme for InterVehicle Communication," in International Symposium on Performance Evaluation of Computer and Telecommunication Systems SPECTS 2002 San Diego, CA, USA, July 2002. [20] A. Ebner, H. Rohling, L. Wischhof, R. Halfmann, and M. Lott, "Performance of UTRA TDD Ad Hoc and IEEE 802.11b in Vehicular Environments," in IEEE Vehicular Technology Conference. vol. 2 Jeju, South Korea, April 2003, pp. 960964. [21] M. Lott, R. Halfmann, and M. Meincke, "A Frequency Agile AirInterface for Inter Vehicle Communication," in ICT 2003 Tahiti, Feb 23 March 1, 2003. [22] M. TorrentMoreno, A. Festag, and H. Hartenstein, "System Design for Information Dissemination in VANETs," in 3rd International Workshop on Intelligent Transportation(WIT), Hamburg, Germany, March 2006, pp. 2733. [23] M. TorrentMoreno, F. Schmidt Eisenlohr, H. Füßler, and H. Hartenstein, "Packet Forwarding in VANETs, the Complete Set of Results," Dept. of Computer Science Universität Karlsruhe (TH) 2006. [24] M. Meincke, P. Tondl, M. Dolores, P. Guirao, and K. Jobmann, "Wireless Adhoc Networks for InterVehicle Communication," in Zukunft der Netze Die Verlezbarkeit meistern, 16. DFNArbeitstagung \über Kommunikationsnetze: GI, 2002.
UbiCC Journal – Volume 3 36
[25] M. Jerbi, S.M. Senouci, and Y. GhamriDoudane, "Towards Efficient Routing in Vehicular Ad Hoc Networks," in UBIROADS 2007 workshop, GIIS Marrakech, Morocco: IEEE, July 2007. [26] M. Mabiala, A. Busson, and V. e. V`eque, "On the capacity of Vehicular Ad Hoc Networks," in UBIROADS 2007 workshop, GIIS Marrakech, Morocco: IEEE, July 2007. [27] "eSafety Forum," http://www.escope.info/. [28] T. Yamamoto, "Transportation and Safety In Japan," IATSS Research, vol. 29, pp. 110113, 2005. [29] J. Njord, J. Peters, M. Freitas, Bruce Warner, K. C. Allred, R. Bertini, R. Bryant, Robert Callan, M. Knopp, L. Knowlton, C. Lopez, and T. Warne, "Safety Applications of Intelligent Transportation Systems in Europe and Japan," American Trade Initiatives Jan. 2006. [30] D. Khadraoui and F. Zimmer, "Carlink Project," in UBIROADS 2007 workshop, GIIS Marrakech, Morocco: IEEE, July 2007. [31] "Network On Wheels," http://www.networkonwheels.de/. [32] A. Aijaz, B. Bochow, F. D¨otzer, A. Festag, M. Gerlach, R. Kroh, and T. Leinm¨uller, "Attacks on Inter Vehicle Communication Systems an Analysis," www.networkon wheels.de/downloads/NOW_TechReport_Atta cks_on_Inter_Vehicle_Communications.pdf. [33] C. Tchepnda, H. Moustafa, H. Labiod, and G. Bourdon, "Securing Vehicular Communications An Architectural Solution Providing a Trust Infrastructure, Authentication, Access Control and Secure Data Transfer," in IEEE Workshop AutoNet 2006 San Francisco, USA, 27 Nov1 Dec 2006. [34] E. Coronado and S. Cherkaoui, "Secure Service Provisioning for Vehicular Networks," in UBIROADS 2007 workshop, GIIS Marrakech, Morocco: IEEE, July 2007.
UbiCC Journal – Volume 3 37