Koji Kamakura
email: koji.kamakura@hds.utc.fr

Bertrand Ducourthial
email: bertrand.ducourthial@hds.utc.fr

Experimental Validation of Cooperative Approach Near Road Side Units

This paper reports an experimental validation of the feasibility of cooperative approach for extending the coverage of vehicular-to-infrastructure (V2I) communication using our software platform named Airplug. Although the access time between a vehicle and a roadside unit (RSU) providing Internet access is limited in the real-world condition, our field trials demonstrate that it is extended by just passing by an RSU with forming a convoy of five vehicles installed Airplug. An overview of our software design and experimental setup is described, and discussed together with results using a WiFi access point (AP) as the RSU. Our field results show that the minimum of increased access time of our cooperative approach is always longer than the maximum of the access time of the single-vehicle case, even though the coverage varies.

I. INTRODUCTION

Many intelligent transportation system (ITS) applications rely on V2I communication to gather data produced by embedded sensors, calculators or embedded applications. Most of these applications do not have strong constraints on the delay and on the messages losses, but on the other hand, the amount of data can be very large. For instance, applications willing to periodically collect data about the vehicle or environment status would not be easily damaged by few message loss or a few second delay, but process as much data as they can.

Although 802.11-based wireless networks in many metropolitan areas around the world have been penetrated, the coverage is limited [START_REF] Ott | Drive-thru internet: IEEE 802.11b for automobile users[END_REF]- [START_REF] Da Silva | A trajectorybased approach to improve delivery in drive-thru Internet scenarios[END_REF]. In [START_REF] Bychkovsky | A measurement study of vehicular Internet access using in situ Wi-Fi networks[END_REF], the median duration of connectivity at vehicular speeds is reported to be 13 seconds. Instead of deploying many RSUs with Wireless Access for Vehicular Environments (WAVE) [START_REF]WAVE Family Standards[END_REF], [6], custom-tailored for vehicular specific applications with an alternative network layer architecture, to cover the roads as it is planned in ITS architectures, such strategies should be considered which vehicles could collaborate to widen the coverage of an RSU. One strategy is the do-it-alone behavior: the vehicle stores the messages until encountering an RSU. This could increase the end-to-end delay of the messages from the vehicle to the destination in the infrastructure. On the one hand the message could never arrive, but on the other hand it could save the bandwidth because there is no vehicle-to-vehicle (V2V) communication for reaching the RSU. Another strategy is the cooperative behavior: the vehicle involves neighbors for sending its messages toward Internet. This approach could reduce the end-to-end delay compared to the do-it-alone one, but on the other hand it could generate many V2V messages. In some case, the network might be congested.

Our cooperative approach we will report here is implemented so that it could involve the benefits of the two behaviors. Our goal is to measure how the coverage of an RSU is enlarged with our approach implemented. To this end, we details our implementation using AIRPLUG and explain how our field test was done with a WiFi AP as an RSU. To assess the coverage achieved, we define the access time as the creation time difference between the first and last messages arriving at the destination while the message source vehicle is passing by an RSU. Our field trials demonstrate that our cooperative approach extends the coverage of the RSU in terms of the access time.

The rest of this paper is organized as follows. In Section II, the software architecture we developed for this validation is described and then the methodology of the field trial and results measured are discussed in Section III. Section IV concludes the paper.

II. OVERVIEW OF EXPERIMENTAL ARCHITECTURE

A. Airplug

Our cooperative V2I architecture has been implemented using the Airplug software distribution [START_REF]The Airplug Software Distribution[END_REF]. This framework allows for easily developing protocols and distributed applications, for studying them through emulation, and for developing them on target architecture (including embedded computers) without rewriting the code [START_REF] Buisset | Vehicular networks emulation[END_REF]- [START_REF] Ali | A light architecture for opportunistic vehicle-to-infrastructure communications[END_REF].

Airplug is a light message passing framework imposing very few conditions on the applications: writing messages on the standard output for sending, reading the standard input for receiving, and satisfying simple conventions of the text message exchange. Airplug applications can be designed using any language. In practice, most of our applications are implemented in Tcl/Tk for easing the deployment on both desktop and embedded PC and for a better integration in Network Simulator ns-2.

The Airplug software distribution is composed of applications, libraries, and specific programs, depending on the mode of use: prototyping, emulation, and real deployment. Applications can exchange messages either locally or remotely following a publish/subscribe policy. The default behavior is to forward messages in the vicinity of a vehicle instead of learning on the neighborhood and exchanging addresses, which is resource consuming in a dynamic network. The cooperative V2I architecture also relies on such opportunistic approach [START_REF] Ducourthial | Conditional transmissions: Performance study of a new communication strategy in VANET[END_REF]: no assumption is made on the existence of a complete end-to-end path from source to destination. Nodes do not require the global knowledge about network topology to forward a message. Routes are built dynamically wherein each node decides to forward or not the message based on local information, implementing a store-carry-and-forward paradigm.

B. Airplug applications

We detail each application composing the cooperative V2I architecture in order to deliver messages from the source to the destination (web server) in our field trial.

The GPS application allows to receive GPS positions from a GPS receiver and to send them to all local applications that subscribed to them. In addition, positions are logged to be used when replaying the experiment in the network emulator of the Airplug distribution.

The TST application (TeST) generates messages to be sent to the infrastructure for the needs of the experiments. TST can subscribe to the local GPS application and then can receive the local position of the vehicle. Messages include timestamps that identifies when they are created at the source node and conformed to a given size and inter-packet gap (IPG). They are sent to the local GTW application (see Fig. 1(b)).

The GTW application (GaTeWay) is in charge of sending messages from local applications to the Internet. We implement two parameters d l and d f , which are date for lifespan and date before forwarding, respectively. GTW can send messages on TCP on a given web server. Every T n seconds, GTW scans networks to discover any gateway including RSU. Moreover, every T s seconds, it processes the received messages, which The HOP application deals with the V2V communication, based on the conditional transmission [START_REF] Ducourthial | Conditional transmissions: Performance study of a new communication strategy in VANET[END_REF]. To avoid managing addresses which are very unstable in a dynamic network, a message is sent with two conditions. When the first one named CUP is true, HOP delivers the received message to the local application. When the second one named CFW is true, HOP forwards the received message to the vicinity of the node. Conditions can be very large and encompass addresses including geographic addresses for implementing geocast, trajectory correlation to determine vehicles on the same lane, duration conditions or the availability of an Internet access (such as a close RSU) [START_REF] Ali | A light architecture for opportunistic vehicle-to-infrastructure communications[END_REF].

For the field trial, CUP and CFW are exclusive and simple. If the local GTW (GTW on the same node) has an interface connecting to a WiFi AP, CUP is true (i.e., CFW is false), or vice verse. If CUP is true, the message is forwarded to the local GTW and sent to the server via its interface (see the right node of Fig. 1(b)). If false, messages are forwarded to other nodes by HOP via the ad hoc mode interface (see the middle node of Fig. 1(b)).

III. FIELD TRIAL AND RESULTS

A. Equipment

To measure the performance in realistic scenarios, we setup an outdoor field environment with five vehicles and a WiFi AP as an RSU. Each of the vehicles was equipped with an AIRPLUG-installed laptop PC, internal antenna, external antenna, and GPS receiver. In the PC, AIRPLUG runs on Ubuntu 13.04 with linux 3.8.0-32 kernel. The internal wireless interfaces of the laptops were used for association of the WiFi AP (managed mode) with GTW, and the external wireless interfaces were used for V2V communication (ad hoc mode) with HOP. The hardware details are listed in Table I.

B. Time Calibration

Consistency, rather than accuracy, of the system clock is needed for precise delay calculation between laptops and web server involved in the field test. Since laptops and servers are left to themselves, they would gain or lose time up to a few hundred milliseconds per hour. To keep one common clock among them during the field trial, their system clocks were calibrated before the field trial, with Network Time Protocol (NTP) and the command adjtimex [START_REF] Mills | Network time protocol version 4 reference and implementation guide[END_REF].

Even if their clocks are perfectly synchronized with NTP service, they will make their own drifts during the trial, in which they are off-lined. Such drifts will make wrong delay calculation in order of ms. While ntpd is running with a reliable time server, the daemon will then measure and record the intrinsic clock frequency offset in the so-called frequency file ntp.drift. After that the current frequency offset is written to the file at hourly intervals. Depending on the computer clock oscillator's frequency error, this may take some hours or days to stabilize. When the value has converged, the frequency file contains the frequency offset measured in parts-per-million (PPM).

Therefore, with tick and frequency of the adjtimex command, the system clock was calibrated so that the ntp.drift should be less than 0.300 ppm, as listed in Table II. The last offset measured before the field trial and the first offset measured after the trial are also listed (Note that the web server was always connected with the NTP server). Before the field trial, the minimum and maximum of the offset difference between the time server is 31.2 µs (v1) and -68.1 µs (v3), respectively; consequently, the maximum offset between the system clocks are 99.3 µs. After the trial (roughly 110 minutes after the last measure), the minimum and maximum differences are 604.6 µs (v1) and -340.1 µs (v4), respectively; the maximum offset difference among them are 944.8 µs. The delay can be calculated in error by less than one millisecond.

C. Driveway

Fig. 2 shows the driveway we used for the field trial. Vehicles passed by the WiFi AP located in the road side (25-m away from the driveway), at the speed of 35 km/h. Messages were generated by TST on the source node every second (IPG = 1000 ms) and sent by GTW on vehicular nodes toward the Web server via the AP. The AP is equipped with a DHCP server and secured using WPA2 Personal. It then assigns IP addresses after the authentication of the PC embedded in the vehicle, for which it took roughly 150-250ms. The 134-meter region shown in Fig. 2 was the coverage of the AP which was measured in a static situation with the internal antenna of the laptop. The driveway environment is so-called "suburban," which 2-or 3-story buildings, trees, frequent traffic lights, and STOP signs, where steel fences exist between the AP and driveway. All trials were conducted in ambient traffic conditions with other vehicles present.

D. Basic scenario and Result

To measure the range of a WiFi AP on the sub-urban driveway, several rounds were carried out. In Fig. 3, left three graphs show the delay of messages calculated from log files of the laptop and web server as a function of the elapsed time of the field trial, which is converted from UTC (Coordinated Universal Time) of the TST message creation time. The right three graphs show the cumulative number of messages. The delay and the cumulative number are on the right-hand side axis. While, on the left-hand side axis of all the graphs, the distance of the vehicle (v1) from the AP calculated from the GPS track is shown with a brawn curve. The origin of the elapsed time is set to the instance at which the vehicle drove through the point closest to the AP for the first time. The top, middle, and bottom ones focus on part of the first, second, and third rounds, respectively, of the trial while the vehicle was approaching and leaving the AP. A red circle shows the amount of time taken for a TST message to be transmitted from v1 to the web server, and a brown vertical line under the red circle on the same point of the time axis shows the amount of time taken until the corresponding message was sent by GTW on v1 after it associated to the AP. The length of the vertical line does not include the propagation time for the message to travel over wireless channel from the sending interface of the vehicle to the receiver (AP) and over the wired network from the AP to the web server, and to be processed at the web server, including three-way hand shaking of TCP. Such times are understood through the gap between the circle and the line, because the plots of the delay performance (the left graphs) are depicted according to the creation time of TST message, a red circle and a vertical line at one point on the time axis correspond to one message created at the time. If there is no red circle over a vertical line, it means that the message did not reach the web server (i.e., lost), although it was sent by GTW.

We can see from the measured delay (left graphs) of Fig. 3 how long the access time was in the basic scenario. In the first round, the first and last messages received by the Web server were created at t = -2.7 and 7.9, respectively. The messages were created every second and ten consecutive circles are observed. Consequently, the access time from the vehicle to the AP for the first lap is 10 seconds. Putting it more precisely in terms of the creation time of TST message, the access time is 10.501 s. The average delay of the messages during the access time was 0.811 s. Similarly, the access times of the second and third rounds were 16 and 8 seconds from the middle and bottom graphs, respectively.

We can also see a tendency that the first two messages in the access time experienced slightly larger delay than the following messages for all the rounds. For example, the delays of the first and second messages were 2.071 s and 1.293 s, respectively, while the others were roughly 160-320 ms typically, as shown in the bottom graph, although some messages were irregularly large without known reasons, like the eighth received message in the first lap and 11th and 14th received messages in the second lap. Such a large delay for the first few messages is certainly due to the route establishment measured at the application level (ARP, IP, DHCP recording update) and web application activation.

The right three graphs of Fig. 3 shows the cumulative number of messages received by the web server and sent by GTW of v1 of the basic scenario. Red circles and vertical lines are depicted according to the receiving time at the web server and sending time at GTW, respectively, unlike the delay performance shown in the left ones. Compared to a circle-line pair standing for a message (on the same time point) of the left graphs, the circle and line for the message in the right ones are shifted to the right along the time axis, depending on their delays. Red circles tend to be placed on the right side off the corresponding vertical lines because they are depicted over the vertical line in the left graphs. The offset between the red circle and vertical line along the time axis indicates the sum of the propagation and processing times on the way to and at the web server. For example, there is a vertical line at t = 5.9 in the top figure. Accordingly, the red circle corresponding to it is depicted almost on the vertical line at t = 6.9, which is the lower one among two red circles. This is confirmed from the gaps for the two messages generated at t = 5.6 and 6.6 in the left graph. The delay of the message at t = 5.6 is beyond one second (1.352 s) and larger than the one at t = 6.6 (0.249 s). This means that they arrived at the web server on almost the same time (i.e., the corresponding two red circles are placed at almost the same time axis). However, the cumulative number of messages received might jump by one message (or more) when we see it along the vertical axis. This means that the sequence number of TST message received were in disorder temporarily, but it would be corrected finally because the delayed messages were counted when they were received.

Note that in the right graphs, two vertical lines for the first two messages in the access time are depicted at almost the same point of the time axis (though it might be difficult to see them overlapping), since the difference between their delays has the tendency of one second.

E. Basic Scenario's Summary

From Fig. 3, the total numbers of messages successfully received by the web server of the first, second, and third rounds are nine, sixteen, and eight, which are interpreted as 9-, 16-, and 8-second access time, respectively. Although GTW sent them eleven and seventeen times in the first and second rounds, respectively, the messages of the last sending attempts are not counted as the access time, because they were lost. On the other hand, the last sending attempt in the third round is counted because it reached the server. Such a failure happens when vehicular nodes moved out the range right before GTW had completed its sending process, despite of detecting the AP and initiating the sending process while it was on the boarder of the range.

We conclude from the results of the basic scenario that at maximum (second round), from the point of 50 m away from the AP, the vehicular node initiated communicating and ended its communication with the AP at the point of 100 m away, which is interpreted as the 16-second access time in terms of the generating time of TST message at maximum (the second round), while at minimum (the third round), from the point of 24 m away (the drive point closest to the AP) to the one of 60 m away, which is interpreted as the 8-second access time.

F. V2V communication

The second scenario was carried out to measure the range of V2V communication, with two vehicles set up in the same way as in the basic scenario. V2V communication in our architecture is implemented as message exchange between HOP on different vehicles via their roof-mounted external antennas. Note that HOP used a wireless interface operating in the ad hoc mode.

In the V2V scenario, two cases were considered. The first one is that at the speed of 35 one vehicle labeled "v1" passed by another vehicle labeled "v2," which stopped in the road side closest to the AP in order to measure one hop communication range with the roof-mounted ad hoc wireless connection. The second one is that v2 went together following five seconds behind of v1 to measure the loss rate of HOP-HOP communication in the driving situation. Fig. 4 shows the delay of the V2V scenario as a function of the elapsed time, where the upper one depicts the first case and the lower one depicts the second one. Similarly to Fig. 3, vertical (brown) lines and red circles are shown, according to the creation time of TST message. The length of the vertical line shows the amount of time taken for a message to be created at v1 and to be sent by GTW on the source node. On the other hand, the red circle shows the amount of time taken for the message to be received by HOP on v2 from its creation time. Consequently, the gap between the red circle and brown line results in the amount of time spent between the two HOPs including the propagation time over the wireless channel. If there is no red circle over a vertical line at a time, it means that the message generated at that time did not reach v2 (for example, at t = 12.5, no red circle is over the vertical line). We observe that the first and last messages arriving at v2 were generated at t = -9.9 and 17.0, at which v1 was 88 m and 147 m away from the AP or 87 m and 121 m away from v2, respectively. In addition, we see that during the access time, among 25 sending attempts, 22 messages reached the server, where the loss rate is 0.12. The reason why the delay of the messages via the relay nodes are larger than two seconds is that they were buffered in GTW for d f • T s seconds before being forwarded to its local HOP. We confirmed from the log files that the processing time taken for messages from being forwarded by GTW to being sent by HOP were negligible (less than 1 ms).

In the lower one of Fig. 4, the delay measured in one of the rounds is shown, where v2 was driven so that it could follow five seconds behind v1. Since the distances shown are calculated from the AP, the gap between the brown and orange curves at one point of the time axis does not indicate the exact distance between them at that moment, the distance between v1 and v2 are summarized in Table III. As shown in the table, the loss rate during the elapsed time shown in the figure is 0.0276, which is much lower than the first case.

G. Cooperative approach

The third scenario is a five-vehicle scenario. Five vehicles were set up in the similar way to the basic scenario. Drivers drove their vehicles so that they should follow in the tracks of the vehicle ahead of them, with keeping the five-second delay, in particular in the 134-m region in front of the AP, shown in Fig. 2. Although they made a right turn at the corner right before entering the region, they got close to each other at the corner for braking, and afterward they tried to drive so that they could follow the vehicle ahead with the delay. Fig. 5 shows the measured delay and cumulative number of messages as a function of the time of the five-vehicle scenario, where the last vehicle in the convoy was the source node generating messages and the other ones acted as the relay node. We can see from the upper graph that for 21 seconds from t = -30 to -9, 17 messages reached the web server, though the source node (v5) was 160 m or more away from the AP at t = -30, where it was out of the range from the results of the basic scenario. We confirmed from the log files that they were sent by v1, v2, v3, or v4. Two red circles are plotted on one point of the time axis, i.e., duplication reception. This is because vertical lines with different colors are depicted at those time points, which means that the message generated at the time point was sent by different nodes and they reached the server with the delay indicated as the gap in the figure. Duplication happened when a message sent by HOP was received multiple remote HOPs on different vehicles, which were in the range of the AP. From t = -5 to 10, messages sent by the source node (v5) reached the server because it was in the range of the AP. The delay exhibits the tendency that the first two messages sent by the source node experience a slightly large delay than the later ones (though the message generated at t = 7 experienced quite large delay of roughly 4 seconds).

In the lower one of Fig. 5, the vertical lines separated by color show the numbers of messages sent by individual nodes, and red circles show the number of messages received by the server. We observe that since v1 started connecting to the AP at t = -27, 24 messages in total reached the server before v5 (the source node) started sending, while seven messages were duplicated. Consequently, 17 messages are correctly received from the relay nodes. For the period of t = -6 to 10, ten messages were received from the source node. In short, 27 messages correctly reached the web server, and then the access time was increased by 17 seconds compared to the case without relay nodes. from t = -23 to -7, 21 messages reached the web server, with six duplicated receptions. In addition, four more messages reached the server from t = 12, which were sent by v5, where no duplication happened. Consequently, 19 messages reached the server via the relay nodes.

From the source node (v3), among 16 sending attempts, 13 messages were received with no duplication for the period from t = -6 to 11. The number of messages correctly received was increased by 19, compared to the single vehicle case.

We also see that the messages via the relay nodes were larger than the one directly sent by the source node. This is because of the buffering time of GTW. Since T s = 200 ms, the maximum buffering time was two seconds in the setting. Since messages sent by the relay nodes had been buffered for the two seconds in GTW on the source node before arriving at the relay nodes, their delay were greater than the buffering time. However, no GTW buffering happened on the relay nodes, because their HOPs forwarded messages to their GTW only if their wireless interface was associated. Such a delay could be reduced if using a smaller value of d f , but more V2V messages would have been generated (more cooperation, less do-it-alone behavior).

IV. CONCLUSIONS

In conclusion, our empirical measurement studies conclude that a line of five airplug-installed vehicles on the road achieves the extended access time of 27 seconds (corresponding to 145 m) at least, which is larger than the maximum access time of the single-vehicle case, 16 seconds (90 m). Our approach will be applied to various infrastructure such as cellular 2G/3G, WiMax, and IEEE 802.11p. We also confirmed the realism and versatility of the results of the emulation mode of AIRPLUG, which is useful for analyzing and optimizing the parameters for the real situation, which is not mentioned because of space limitations.

Fig. 1 .

 1 Fig. 1. (a) Scenario of vehicles passing by an isolated RSU providing an Internet access. (b) Airplug architecture: Red arrow shows a message flowwhen it is sent to the web server by the TST source node if it finds the AP via a network interface operating in managed mode. Blue arrows show a message flow when it is forwarded to other HOPs via a network interface operating in ad hoc mode if the source node does not find any AP. HOPs on different nodes receiving the message choose their behavior depending on whether their GTW finds an AP. If not, the message is forwarded the same way as the source node, as shown with blue arrows in the middle node. If GTW does, the HOP forwards it to GTW and then it is sent to the AP via the manage-mode interface, as shown with green arrows in the rightmost node.

Fig. 2 .

 2 Fig.2. The driveway of our field trial is shown in orange, which has a 134-meter region measured in advance that the laptops were associated to the AP via their internal antennas in the static situation. The AP was located on the roof of the garage, which is 25 m away from the driveway.

Fig. 3 .

 3 Fig. 3. Delay (left three graphs) and cumulative number (right three graphs) of messages received by the web server (red circles) and sent by GTW of the vehicular (vertical lines) as a function of the elapsed time. Circles and vertical lines are depicted with the reception time of the corresponding TST messages.

Fig. 4 .

 4 Fig.[START_REF] Bychkovsky | A measurement study of vehicular Internet access using in situ Wi-Fi networks[END_REF]. The amount of time it took to be received by HOP on v2 and to be sent by HOP on v1 (moving and leading vehicle) (vertical lines) as a function of the elapsed time t, where 500 ≤ t ≤ 700.

Fig. 6 Fig. 5 .

 65 Fig.6shows the measured delay and cumulative number of messages, where the middle vehicle (v3) was the source node. From the upper graph, we can see that for 21 seconds

Fig. 6 .

 6 Fig.6. Delay and cumulative number of TST messages received by the web server (red circles) and sent by GTW of the vehicles (vertical lines) as a function of the elapsed time, whose origin is the time at which the TST-source node (v3) was closest to the AP.

TABLE I

 I In case a gateway is available, they are sent to the web server, or else d l and d f are decremented. When d l expires, the message is discarded. When d f expires, the message is forwarded to the local HOP application. The delay parameters d f and d l are counted every T

	.	DETAILS
	Laptop (PC)	Dell Inspiron Mini 9
	OS	Ubuntu 13.04 Linux 3.8.0-32 kernel
	CPU	Intel Atom N270 / 1.6 GHz (single core)
	Memory	DDR2 SDRAM (1,024MB)
	Internal WiFi	2.4 GHz, 802.11b/g Wi-Fi
	USB WiFi adapter	Alfa AWUS036EH
	WiFi	2.4 GHz, 802.11b/g
	Chipset	Realtek RTL8187L
	Magmount External antenna	MARS Antennas MA-WO25-CTBM
	Gain	+4 dBi
	GPS Receiver	GlobalSat BU-353
	Chip	PL2303 Serial Port
	WiFi access point	Linksys WRT160NL
	Band	2.4 GHz
	Channel	10 (2.457 GHz)
	Height from the surface of the driveway	2.7 m
	have been stored waiting for a network.

s seconds. For instance, if T s = 200 ms and d f = 10, the maximum time of a message buffered by GTW is 2 seconds.

TABLE II .

 II

				TIME CALIBRATION
	Node	Tick	Frequency	Drift (ppm)	Last offset (s)	First offset (s)
	v1	9999	5821269	0.221	0.000031163	0.000604642
	v2	10001	-5604015	0.042	-0.000024584	-0.000088086
	v3	10001	-5753498	-0.290	-0.000068095	-0.000100521
	v4	10001	-5770689	0.188	-0.000027059	-0.000340140
	v5	10001	-5445938	-0.123	-0.000014923	0.000351801
	web	10000	3442123	-0.023	0.000010680	-0.000018161

TABLE III .

 III

		RESULT SUMMARY
		Overall of Fig. 4(b)	134-m region
	Elapsed time	t=500: 1385561911	t=545:1385561956
	TST sequence number	727	767
	Elapsed time	t=700: 1385561211	t=590: 1385561996
	TST sequence number	907	803
	Number of messages sent at v1	181	37
	Number of messages received at v2	176	36
	Loss rate	0.0276	0.02702
	Average delay	2.042 s	2.038 s
	Standard dev.	69.3 ms	56.5 ms
	Minimum	1.900 s	1.900 s
	Maximum	2.312 s	2.136 s
	Average distance between v1 and v2	25.71 m	38.62 m
	Standard dev.	17.18 m	6.48 m
	Minimum	1.18 m	32.60 m
	Maximum	71.06 m	46.58 m

ACKNOWLEDGMENT

The authors would like to thank P. Crubillé, G. Dherbomez, P. Hudelaine, S. Bonnet, G. Sanahuja, and J. Radak for their help with the experiments.


Farah El

Bertrand Ducourthial

Keepalive service for VANET applications

Keywords: vehicular networks, applications, services

Many applications are designed for vehicular networks, like chat, dynamic map update or touristic information. The need of services used as building blocks for these applications is then emerging: localization, map matching, data collect, and so on. When a unicast communication is required, applications rely generally on naming, localization and routing services. This approach consumes many network resources and leads to poor performances when the network dynamic is high. We then propose an efficient service, named keepalive, to ensure the continuity of a communication that began between two mobile neighbors. The major strengths of our proposal are that it relies only on local exchanges of identifiers and it is less resource consuming than usual networking services. Moreover, it is beneficial for a large set of applications, including download from road side units or follow me application for instance. Road tests and performance study confirm the efficiency of the keepalive service.

I. INTRODUCTION

A PPLICATIONS for vehicular networks in particular, and dynamic networks in general, are expanding widely. These applications are designed for costumer services, road safety issues or traffic management. We can name the follow me application that helps the exchange of information between two cars moving towards the same destination, or the RSUdownload application that ensures the data transfer between a road side unit and a car, in order to receive information.

All these applications rely on underlying services to be able to function properly and satisfy the needs of the users. Some of them need to retrieve information from the Controller Area Network (CAN) bus of the vehicle through a gateway to receive data from embedded sensors and calculators. Other applications require a map matching service to localize the vehicle on a map with a confidence indication. Others need to periodically collect data from the environment, and so on.

Usual networking services have been proposed too, such as naming, localization services, routing, and so on. However some of these services may consume resources when the network is highly dynamic. In some situations, the traffic road admits a reasonable dynamic (e.g., highways or country roads). This is not the case in a city with dense traffic, crossroads, traffic lights and so on. In such a situation, when two vehicles wish to maintain a communication (as in the follow me application), many networking resources will be used. It is the same with the RSU-download application when the vehicle cannot stay enough time in the range of the RSU. In these cases, an efficient dedicated services would be preferable.

The above mentioned applications -follow me and RSUdownload -need to maintain the started communication Laboratory Heudiasyc UMR CNRS UTC 7253, Université de Technologies de Compiègne, 60200 Compiègne France.

Labex MS2T Maîtrise des Systèmes de Systèmes Technologiques between the source (first vehicle or RSU) and its destination. A keepalive service is then essential when the entities are mobile, to prevent the communication from being broken. When applications rely on usual networking services, many control messages are generated. Let take the example of the follow me application and consider two instances A and B of this application running on two different vehicles. These instances are known to each other by their identifiers defined at the application level. To establish and maintain the communication, the routing layer requires network addresses. Thus, another service is called, a naming service or a localization service depending on the kind of addressing scheme. However, these addresses will change because of the mobility of the cars running A and B, and then the naming/localization service requires regular updates of its data structures (local caches or remote database). Generally such services need broadcast communications and consume bandwidth [START_REF] Altayeb | A survey of vehicular ad hoc networks routing protocols[END_REF].

Suppose now that the address resolution is solved. The problem is then to route messages between two nodes known by their network addresses. In a dynamic network, this task is not simple and, in some situations, can generate many control messages. For instance, broadcast are generally used to repair a route or when the destination is not known precisely [START_REF] Perkins | Ad hoc on-demand distance vector (AODV) routing[END_REF].

Hence, when an application requires to establish a route between two moving vehicles, naming/localization and routing services may lead to a large control overhead. However, some applications could perform better when relying on new services. In this paper, we propose a keepalive service that replaces the naming/localization and routing services for a large set of applications with the particularity to establish the communication while the nodes are neighbors. We believe that this will be the case for most of the unicast communications in dynamic networks. Therefore, our service will be beneficial for a large set of applications.

The keepalive service relies on cars identifiers to manage the communication and proceeds only to local exchanges of messages in the neighborhood of the concerned vehicles. Therefore, remote information and broadcast communications are not needed and applications' performances increase.

In the next section, we show that in most applications some optimizations are possible by replacing usual networking service with our keepalive service. Then in Section III, we detail our protocol. We show its interest using road tests and performance studies in Section IV. Comparison with related work and concluding remarks end the paper.

II. KEEPALIVE SERVICE DEFINITION

A. Applications needs

As explained in the previous section, initiating a communication with a remote node at the application level solicits services such as naming or localizing that consumes resources when running in dynamic networks. Moreover, routing can overload the network in some situations.

However, vehicular networks are not a general purpose network. Applications requiring to establish a communication with a remote node will certainly use an operated network, as provided by 4G for instance. Many applications designed for the ad hoc vehicular networks will be specific. We believe that most of them will initiate unicast communication by evidence and naturally when the two protagonists are neighbors. In that case, they share a common interest, such as traffic information, touristic information, and so on.

For instance, when the follow me application starts, the vehicles are supposed to be neighbors, one behind the other at the beginning of the trip. In the same way, the RSU-download application will certainly starts when the vehicle requests it while it is in the range of the road side unit (illustrated in Figure 2). Similarly, chats (illustrated in Figure 1), images or video transfers will certain be done while the users are in interaction due to the proximity. Hence, it is possible to exploit this specificity to design an efficient keepalive service, offering the continuity of the unicast communication to the application layer. Such a service could only rely on identifiers exchanged in the neighborhoods instead of network addresses. Identifiers remain stable during the application (to the contrary of network addresses) and can be managed at the application layer easily.

B. Principle

The keepalive service is illustrated in Figure 3. The first step is to initiate a communication between two neighbor nodes. This can be done for instance using a local broadcast at the network layer followed by a pseudonym filter at the application layer. For some applications, cryptographic keys or peering codes can be exchanged using another channel, as it is used for peering Bluetooth devices. For instance, codes could be exchanged before starting the vehicles in the follow me application for securing the communication. In other applications, the license plate number could be entered after having been seen by the close users. In case the IEEE WAVE stack is used, the communication could be set using the Wave Short Message Protocol (WSMP) and a Provider Service Identifier (PSID) identifying the application [START_REF] Uzcátegui | Wave: a tutorial[END_REF].

Then messages can be exchanged between two instances of the service, running on neighbor nodes (Figure 3-left). If the distance between the nodes increases up to the communication range, other instances of the service running in close vehicles will propose to become relay. Note that in case there is no such nodes, then either the ad hoc network is disconnected or there is a longer path that should be discovered. In the first case, the communication is impossible. In the second case, discovering such a path will require to flood the network. Moreover the duration of the path is generally short because each of its links shares the same characteristics as the broken one. Hence, the keepalive service will only rely on close nodes.

The path will then grow (Figure 3). When the vehicles come closer to each other, useless relays must be removed.

The path adjustments are done on the basis of local information exchanged in the neighborhood of the concerned nodes only. Hence the load on the network is drastically reduced. Moreover, when messages from the application layer are sent over the path, the control information is piggybacked to the messages. When a node forwards the received message, the previous sender receives an indirect acknowledgment. The control information consists in the local knowledge about the path as well as some flags allowing to exchange states about neighbors: sender, receiver, uncertainty about its identifier and so on. It is important to note that only local information is used, avoiding overhead due to remote information update.

III. KEEPALIVE PROTOCOL

In this section, we describe the underlying protocol of the keepalive service. For sake of simplicity a single sourcedestination communication is considered. The protocol is based on three mechanisms described hereafter: local periodic messages, path extension and path reduction.

A. Periodic messages

The local periodic updates allow to deal with neighborhood changes and link failures. Each node involved in the communication sends periodically a message in its neighborhood for announcing its position in the path. In case a node does not receive this message anymore in a certain time interval, it concludes that the link is broken. These periodic sending are local, and involve only nodes of the path.

The periodic messages contain the list of nodes' identifiers belonging to the path (e.g., u 0 u 1 u 2 u 3 u 4 u 5 ) along with two flags (Figure 4). The first flag (represented by symbol >) indicates the sender of the message along with its successor. For instance, if u 2 is the sender and u 3 is its successor in the path, the message looks like u 0 u 1 u 2 >u 3 u 4 u 5 , as in Figure 4. When resent by u 3 to its neighbors, the message will contain u 0 u 1 u 2 u 3 >u 4 u 5 . Node u 2 will also receive it and will deduce that its last message has been received by its successor. The first message between, say nodes u and v is u>v and the acknowledgment sent by v is uv>.

u 0 u 1 u 2 >u 3 u 4 u 0 u 1 u 2 u 3 u 4
Fig. 4. Messages periodically sent by u 2 to its neighbors indicate its position in the path as well as the identity of its current predecessor and successor.

The second flag, called uncertainty flag and represented by the symbol ?, is used in case of problem regarding a node. For instance, if u 2 has a doubt on its successor u 3 , its message looks like u 0 u 1 u 2 >u 3 ?u 4 u 5 (see Figure 5). The uncertainty flag can also be used on the preceding node. Indeed, a message sent by u 3 should be received by any node in its neighborhood, including both u 2 and u 4 . By sending u 0 u 1 u 2 ?u 3 >u 4 u 5 , node u 3 informs its neighbors that it suspects u 2 to have left the neighborhood (see Figure 6). All this control information is sent periodically using an adjusted timer, either by piggybacking of the application messages or in standalone messages when they are not enough application layer messages.

B. Path extension

The path extension mechanism permits to deal with link breaking, which can happen when two neighbors go far from each other. When receiving messages from both extremities of a link containing uncertainty flags on one another, the neighbor nodes can propose to become relays of the broken communication.

Consider for example Figure 4 and suppose that link (u 2 , u 3 ) breaks. Since node u 2 sends periodically messages containing u 2 >u 3 (as illustrates in Figure 4), it expects implicit acknowledgment of u 3 , that is a message without uncertainty, containing u 2 u 3 >. Such messages indicate that u 3 well receives the message of u 2 and forwards it with the path u 2 u 3 > to the next node in that path.

If node u 2 does not receive such messages from u 3 , it sets the uncertainty flag on its successor u 3 in its next messages, containing u 2 >u 3 ? as in Figure 5. Similarly, if u 3 does not receive other messages from u 2 , it will send messages containing u 2 ?u 3 >u 4 as in Figure 6. This leads to the situation shown in Figure 7.

...u 2 >u 3 ?... If a neighbor node v notices such messages containing the uncertainty flags, it counts them. When a given threshold is reached, it proposes to be relay of the communication by sending a message containing u i ?v>u j ?.

As several neighbors of both u 2 and u 3 may propose to be relays, u 2 (closer to the source of the path) chooses the first (say v) and sends a message containing u 2 >vu 3 ?. Then v sends u 2 v>u 3 ?. Then u 3 sends u 2 vu 3 > and the path is repaired: there are no more uncertainty flags (see Figure 8).

C. Path reduction

The third mechanism, called path reduction, consists in reducing the path whenever it is possible.

Consider the case depicted in Figure 9. By receiving messages sent by u 1 and u 4 (which contain path information), node v observes that it can reduce the path, becoming a new relay node for the path. Subsequently v proposes the reduction by placing in the path the shortcut denoted by u 1 -?v-?u 4 , with an uncertainty flag on the links (u 1 , v) and (v, u 4 ). The message sent by v contains then u 1 -?v-?u 4 u 2 u 3 v>u 4 (Figure 9).

When u 4 receives this message, it confirms to v the possibility of reduction, removing the uncertainty flag on the reduction link (v, u j ) (message 2 in Figure 9). Then messages from v will no more contain the uncertainty on link (v, u 4 ). Node u 1 will consider the reduction proposed by v and will propagates it along the path by sending from this time forward messages containing u 1 -v -u j >u 2 u 3 u 4 . The reduction information will then be forwarded along the path by u 2 and u 3 and will eventually reach u 4 . However, in case one of the nodes between u 1 and u 4 is already engaged into a reduction, it will not forward the reduction by v. This prevents any path disconnection.

When receiving the reduction proposed by v from its predecessor u 3 , node u 4 knows that this reduction has been accepted by u 1 and all other nodes between u 1 and itself in the path. There is then no risk of path disconnection. Finally, node v sends a message containing u 1 vu 4 >, confirming to v that the reduction is effective.

By using this acceptance mechanism on all the nodes in the path between u 1 and u 4 , the protocol prevents any path disconnection due to several overlapping reductions occurring simultaneously. If a node is already engaged in another reduction, it will not forward the validation message containing the reduction. Hence, any conflict between reductions is solved using a lock on the common sub-path: the winning reduction is the first that will be received by nodes of the common subpath.

Through the same mechanism, the reduction can be performed by a node belonging to the original path. In case of conflict, priority is given to the node closer to the destination (it reaches the common sub-path first because it is itself in the common sub-path). The rest of the analysis is similar to the one shown in Figure 9.

(1)(3) (1) (3)
(1) ...u 1 -?v-?u 4 u 2 u 3 v>u 4 ... [START_REF] Altayeb | A survey of vehicular ad hoc networks routing protocols[END_REF] ...u 1 -?v-u 4 u 2 u 3 u 4 >... [START_REF] Buisset | Vehicular networks emulation[END_REF] ...u 1 -?v-u 4 u 2 u 3 v>u 4 ... (4) ...u 1 -v-u 4 >u 2 u 3 ... [START_REF] Ducourthial | A platform for road experiments[END_REF] ...u 1 -v-u 4 u 2 >u 3 ... [START_REF]Designing applications in dynamic networks: The Airplug Software Distribution[END_REF] ...u 1 -v-u 4 u 2 u 3 >u 4 ... [START_REF] Ali | Communication unicast dans les réseaux mobiles dynamiques[END_REF] ...u 1 vu 4 >...

IV. EXPERIMENTAL VALIDATION

The protocol described in the previous section has been studied formally [START_REF] Ali | Communication unicast dans les réseaux mobiles dynamiques[END_REF] and has been implemented using the Airplug framework [START_REF]Designing applications in dynamic networks: The Airplug Software Distribution[END_REF]. The framework permits road experiments and performance studies through network emulation.

A. Airplug framework

Airplug is a light communication middleware designed for dynamic networks [START_REF]Designing applications in dynamic networks: The Airplug Software Distribution[END_REF]. It is characterized by its simplicity and robustness in the messages exchange for in-vehicle and intervehicle communications. Any language can be used within the Airplug framework. However Tcl/Tk is generally preferred for compatibility with ns-2 [START_REF] Khalfallah | Bridging the gap between simulation and experimentation in vehicular networks[END_REF]. The keepalive service has been implemented in Tcl/Tk as an Airplug application named PTH.

The Airplug middleware offers several modes, allowing to use a given application in different ways without further modifications:

• airplug-live: environment for real tests on vehicles or other dynamic networks (as illustrated in Figure 1) [START_REF] Ducourthial | A platform for road experiments[END_REF]; • airplug-emu: environment for emulating dynamic networks in a personal computer (PC). It permits, for instance to replay real tests while changing parameters or adding vehicles [START_REF] Buisset | Vehicular networks emulation[END_REF]. • airplug-ns: adds-on for ns-2 allowing to reuse Tcl code of the application in a large simulation [START_REF] Khalfallah | Bridging the gap between simulation and experimentation in vehicular networks[END_REF]; • airplug-rmt: environment allowing to export an application on another computer while still being connected to the framework.

B. Proof of concept on the road

In order to test the interest of our approach as well as to validate our implementation, we designed a chat application running on Android phones connected through bluetooth to the vehicles' on-board computer. The Airplug applications running on this embedded computer are:

• the Airplug core program (APG) that manages message exchanges and network interfaces; • the Airplug Bluetooth application (BTH) that is in charge of communicating with the users' devices; • the Airplug Chat application (CHT) that requires the keepalive service; • the Airplug PTH application implementing the keepalive service, used by CHT. The CHT application can either be used on the PC or from the Android phones (illustrated in Figure 1). This is a generic application for exchanging messages between remote users and it could be used as a basis for the follow me application. Each message sent by CHT are relayed by the local PTH application to neighbors until the destination. In case no message is produced by CHT, PTH will produce its own to check the path. Else the control information is sent with the CHT payload. In case a link breaks, a relay node is inserted. In case useless relays are present, they are removed as explained in the previous section.

The proof of concept involved six vehicles. The embedded computers were Dell mini-9 Model DP118 under Ubuntu v8.04 Hardy Heron, external USB GPS devices and external USB WiFi antennas Alfa AWUS036EH. The Android phones were Motorola Atrix under Android 2.3.

During the scenario, two cars started a communication while they were close to each other. Then the first car accelerates, creating the space for other cars to be inserted into the path between the first two vehicles, in order to keep their communication alive. Next the first vehicle slows down, allowing a path reduction. Two traffic conditions have been used: Compiègne down-town and high-speed road close to Compiègne.

This proof of concept confirmed that our protocol is able to maintain a communication between two vehicles in different real traffic conditions, showing its usability and interest.

C. Measure of performances 1) Method: Analytical studies validated our protocol [START_REF] Ali | Communication unicast dans les réseaux mobiles dynamiques[END_REF] and on-road tests validated its implementation (previous section). However, in order to complete the evaluation, it is interesting to estimate the gain in terms of number of messages compared to usual networking services. As it is not possible to obtain repeatable experiments on the road (due to traffic among other parameters), we used the network emulation mode of the Airplug framework [START_REF] Buisset | Vehicular networks emulation[END_REF].

With Airplug-emu, scenarios are described in an XML file, GPS traces logged during road tests are replayed for vehicles moves and real applications are used. The Airplugemu application manages vehicles moves and communications between applications involved in the emulation, according to the geographic positions. Figure 10 shows a large scenario (described hereafter) obtained from several real road tests. 2) Scenarios: Two scenarios have been used for the performance study. First, we replayed by emulation the highspeed road scenario from the proof of concept. In this scenario (named high-speed road scenario in the following) traffic is sparse and regular. Then, we mixed several road tests in order to obtain a realistic down-town scenario with larger density (Figure 10) and less regularity. In this scenario (named downtown scenario in the following), 31 vehicles are involved. The communication begins between two vehicles moving from the Research Center to the train station in Compiègne. The path involves up to four vehicles (a screenshot movie of this emulation is available on-line [START_REF]PTH emulation screenshots[END_REF]).

We performed a comparative evaluation of PTH against a greedy geographic routing in the two scenarios: high-speed road and dense down-town. The geographic routing relies itself on a location service to know the position of the destination. When this position is known, the sender sends its message towards the geographic zone containing the destination. When the message reaches the borders of this zone, it is broadcast to reach the destination.

3) Results: We denote by N the number of generated messages on the source node. These messages are forwarded to the destination using the keepalive services. Consequently, we express the total number of messages sent on any link of the network as a function of N .

a) High-speed road scenario: In this sparse and regular network, all nodes are involved in the path. As shown in Table I, the geographic routing produces 2.3N messages, whereas our implementation of the keepalive service produces 2.6N messages. This difference is explained by the fact that the destination must acknowledge the received messages by retransmitting a message (to its predecessor). To the contrary, this retransmission is not required with the geographic routing. Hence the destination node sends less messages over the network. Finally, the geographic routing involved one more vehicle than PTH to ensure the communication (Table I). b) Down-town scenario: In this dense and irregular scenario, 31 vehicles are present with a path increasing up to length 4. The geographic routing with its location service produces 5N messages. On the same scenario, our implementation of the keepalive service produces only 2.4N messages, avoiding to load excessively the network.

Furthermore, in this scenario, all the 31 vehicles are involved in the operation of the geographic routing, whereas only 6 are used by PTH (Table II). As we can see, PTH is advantageous when it comes to dense networks, compared to other routing protocols because very few vehicles are concerned by the communication. As a conclusion, our keepalive service admits similar performances compared to geographic routing in sparse networks and reduces drastically the load over the network in dense scenarios. We see that the keepalive service not only reduces the total number of messages produced in the network for the same demand by the application (here the application wishes

Fig. 1 .

 1 Fig. 1. Convoy of vehicles in Compiègne. The chat application starts a communication between two cars in the convoy and uses the keepalive service.

Fig. 2 .

 2 Fig. 2. An RSU built at UTC and used to exchange information with passing vehicles. The RSU-download application allows for instance to update maps.

Fig. 3 .

 3 Fig. 3. When a link breaks, a neighbor is inserted to prevent the communication from being broken. Only local adjustments are required.

Fig. 5 .

 5 Fig. 5. The message sent by u 2 indicates that it suspects a problem on the link (u 2 , u 3 ).

Fig. 6 .

 6 Fig.6. The message sent by u 3 indicates that u 3 suspects a problem on the link (u 2 , u 3 ).

Fig. 7 .

 7 Fig.7. Extremities of the broken link add an uncertainty flag in their periodic messages. This process is repeated a limited number of times.

Fig. 8 .

 8 Fig.8. A neighbor node v proposes to become a relay between u 2 and u 3 . Node u 2 will confirm to a single relay. When node u 3 confirms in turns v by removing the last uncertainty flag, the path is repaired.

Fig. 9 .

 9 Fig. 9. Messages exchanged during the path reduction proposed by node v.

Fig. 10 .

 10 Fig. 10. A screenshot of the execution of the keepalive service using the vehicular networks emulator Airplug-emu on the down-town scenario.

5 N

 5 is the number of messages generated by the source node.

6 N

 6 is the number of messages generated by the source node.

  ...u 2 ?u 3 >u 4 ...

	v
	u 2	u 3
	...u 2 >u 3 ?...	...u 2 ?u 3 >u 4 ...
	...u 2 >u 3 ?...

...u 2 ?u 3 >u 4 ...

TABLE I KEEPALIVE

 I VS. GEOROUTING IN SPARSE AND REGULAR NETWORK

TABLE II KEEPALIVE

 II VS. GEOROUTING IN DENSE NETWORKS

to send N messages), but also reduces to the minimum the number of cars involved in the transmissions.

V. RELATED WORKS

Applications for mobile networks have grown in number and in variety. Some of these services concern entertainment applications, like video streaming for example [START_REF] Piñol | Modeling video streaming over VANETs[END_REF], [START_REF] Park | Emergency related video streaming in VANET using network coding[END_REF], [START_REF] Qadri | Robust video streaming over an urban VANET[END_REF], and some others concern road safety or safety critical applications, like exchanging traffic information for example. Other applications concern commercial purposes [START_REF] Watfa | Advances in Vehicular Ad-Hoc Networks: Developments and Challenges[END_REF], or data dissemination [START_REF] Cherif | Efficient data dissemination in cooperative vehicular networks[END_REF]. A survey of these applications is detailed in [START_REF] Lee | Emerging Vehicular Applications[END_REF]. These applications usually use the services deployed in these networks.

New infrastructures are being proposed to offer the cooperation between cars as a service and allow the sharing of many services. In [START_REF] Mousannif | Cooperation as a service in VANETs[END_REF], the authors propose a novel architecture that permits to share a set of services for free without any additional infrastructure.

In terms of safety critical applications and services, in [START_REF] Ma | Reliability analysis of one-hop safetycritical broadcast services in VANET[END_REF], the purpose is to ensure the reliability of one hop safety critical broadcast services. For video conferencing, the aim is to be able to distribute contents to all participants. In [START_REF] Le | Application-aware cost function and its performance evaluation over scalable video conferencing services on heterogeneous networks[END_REF], the authors propose an evaluation platform for scalable video conference service. On the other hand, in [START_REF] Zhang | Dynamic differentiated service management for ip over broadcasting network[END_REF], the authors propose a dynamic differentiated service management to provide QoS for delivering IP applications on the IP-Broadcasting Gateway equipment.

Many services and applications use the location service. Securing these location based applications is essential. In [START_REF] Lu | A dynamic privacy-preserving key management scheme for location-based services in VANETs[END_REF], the authors study a new approach for efficient privacy preserving and improving the key update efficiency of Location Based Services. In [START_REF] Pathak | Securing location aware services over VANET using geographical secure path routing[END_REF], a secure location aware services using geographical secure path routing is proposed.

Many work deal with routing in vehicular networks to support the ITS services. Geographic routing relies on a location service (which generally uses flooding) to discover the position and the address of its destination. When the address is well known to the source, the relay node is the closest neighbor to the destination (greedy routing). Two surveys of protocols designed for vehicular networks are presented in [START_REF] Lin | Routing protocols in vehicular ad hoc networks: A survey and future perspectives[END_REF] and [START_REF] Altayeb | A survey of vehicular ad hoc networks routing protocols[END_REF]. In [START_REF] Taleb | A stable routing protocol to support its services in VANET networks[END_REF], the authors propose a new scheme for a stable routing protocol to support ITS Services in VANET Networks.

VI. CONCLUSION

Many applications are emerging in VANET. They rely on the underlying services deployed in the network. However, usual networking services such as naming, localization or routing are not always pertinent in these networks because they turn to be costly in terms of messages and resources when the network dynamic becomes high.

In this paper, we proposed a new service named keepalive, which is advantageous for a large set of applications, including chat, follow me, RSU-download, map sharing among others. This service relies on identifiers to manage the communication and proceeds only to local exchanges of messages in the neighborhood of the concerned vehicles. Therefore, addresses, remote information or broadcast communications are not needed and applications' performances increase.

We presented a proof of concept on road and a performance study using network emulation to replay road tests with some variants while using the same code as the one deployed on the road. The proof of concept showed the interest of such a service. The performance study proved its efficiency in terms of messages saved and vehicles involved.

In future work, we plan to organize new large road tests, to improve our prototype and to measure the performance gain offered by the keepalive service with the RSU-download application.

The authors wish to thank their colleagues for their help during road tests.


Keywords: metastatic prostate cancer, PSA, NLMEM, joint model, SAEM

In metastatic castration-resistant prostate cancer (mCRPC) clinical trials, the assessment of treatment efficacy essentially relies on the time-to-death and the kinetics of prostatespecific antigen (PSA). Joint modelling has been increasingly used to characterize the relationship between a time-to-event and a biomarker kinetics but numerical difficulties often limit this approach to linear models. Here we evaluated by simulation the capability of a new feature of the Stochastic Approximation Expectation-Maximization algorithm in Monolix to estimate the parameters of a joint model where PSA kinetics was defined by a mechanistic nonlinear mixed-effect model. The design of the study and the parameter values were inspired from one arm of a clinical trial. Increasingly high levels of association between PSA and survival were considered and results were compared with those found using two simplified alternatives to joint model, a two-stage and a joint sequential model.

We found that joint model allowed for a precise estimation of all longitudinal and survival parameters. In particular the effect of PSA kinetics on survival could be precisely estimated, regardless of the strength of the association. In contrast, both simplified approaches led to bias on longitudinal parameters and two-stage model systematically underestimated the effect of PSA kinetics on survival.

In summary we showed that joint model can be used to characterize the relationship between a nonlinear kinetics and survival. This opens the way for the use of more complex and physiological models to improve treatment evaluation and prediction in oncology.

Introduction

Prostate cancer is the second most frequently diagnosed cancer in men and is responsible for about 300 000 deaths worldwide every year [START_REF] Ferlay | GLOBOCAN 2012 v1.0, Cancer Incidence and Mortality Worldwide: IARC CancerBase[END_REF]. Although treatment can be effective, a number of factors, such as resistance or delayed treatment (4% of cancer have metastasized at diagnosis [START_REF] Howlader | SEER Cancer Statistics Review[END_REF]) considerably worsen the treatment outcome. In the case of metastatic castration-resistant prostate cancer (mCRPC), the evaluation of chemotherapy efficacy primarily relies on the overall survival [START_REF] Tannock | Aflibercept versus placebo in combination with docetaxel and prednisone for treatment of men with metastatic castration-resistant prostate cancer (VENICE): a phase 3, double-blind randomised trial[END_REF] and is complemented by the analysis of the Prostate-Specific Antigen (PSA). Although countless studies have explored the relationship between different PSA kinetic parameters (such as doubling time or time to nadir) and survival, the choice of a clearly-defined parameter remains controversial.

The lack of consensus on how to use PSA kinetics is exacerbated by the difficulty to properly handle PSA kinetics and the time-to-event (time-to-death or dropout) in statistical models. Several methods have been proposed in the literature. The simplest one is to plug the individual PSA kinetic parameters into a survival model [START_REF] Petrylak | Evaluation of Prostate-Specific Antigen Declines for Surrogacy in Patients Treated on SWOG 99-16[END_REF]. However the fact that these parameters are often not directly observed from the data makes this approach error prone. A second approach is to use a model to describe the entire PSA kinetics using mixed-effect models to precisely account for between-subjects variability, and then to plug individual model predictions as covariates in a survival model [START_REF] Proust-Lima | Determinants of change in prostate-specific antigen over time and its association with recurrence after external beam radiation therapy for prostate cancer in five large cohorts[END_REF][START_REF] Murawska | A Two-Stage Joint Model for Nonlinear Longitudinal Response and a Time-to-Event with Application in Transplantation Studies[END_REF]. However this method, called in the following "two-stage" approach, is prone to bias because it does not take into account the relationship between the marker's kinetic and the time-to-event and the uncertainty in the individual model predictions [START_REF] Wu | Analysis of Longitudinal and Survival Data: Joint Modeling, Inference Methods, and Issues[END_REF]. In order to eliminate the bias found in the two-stage approach, one can use models which simultaneously, or "jointly", handle longitudinal and time-to-event data [START_REF] Wu | Analysis of Longitudinal and Survival Data: Joint Modeling, Inference Methods, and Issues[END_REF][START_REF] Sweeting | Joint modelling of longitudinal and time-to-event data with application to predicting abdominal aortic aneurysm growth and rupture[END_REF][START_REF] Ibrahim | Basic Concepts and Methods for Joint Models of Longitudinal and Survival Data[END_REF][START_REF] Taylor | Surrogate markers and joint models for longitudinal and survival data[END_REF][START_REF] Wulfsohn | A Joint Model for Survival and Longitudinal Data Measured with Error[END_REF][START_REF] Tsiatis | Joint modeling of longitudinal and time-to-event data: an overview[END_REF][START_REF] Hsieh | Joint Modeling of Survival and Longitudinal Data: Likelihood Approach Revisited[END_REF]. For the latter, one can either aim to estimate all parameters simultaneously ("joint" model) or in a sequential manner ("joint sequential" model), as it has been suggested in the pharmacometric field [START_REF] Zhang | Simultaneous vs. sequential analysis for population PK/PD data I: best-case performance[END_REF].

The main challenge in using joint model is the numerical complexity involved by the calculation and the maximization of the likelihood. This difficulty can be circumvented by using a linear model for the PSA kinetics as implemented in the large majority of published models [START_REF] Wu | Analysis of Longitudinal and Survival Data: Joint Modeling, Inference Methods, and Issues[END_REF][START_REF] Henderson | Joint modelling of longitudinal measurements and event time data[END_REF] or softwares [START_REF] Rizopoulos | Joint Models for Longitudinal and Time-to-Event Data: With Applications in R[END_REF]. However this precludes the use of physiologically more accurate models for PSA kinetics which are in essence nonlinear.

In the last years, pharmacometric softwares have addressed the need for joint model when the longitudinal model is defined by a nonlinear mixed-effect model (NLMEM). This approach was firstly implemented in NONMEM using a Laplacian approximation of the likelihood and was essentially used to account for informative dropouts [START_REF] Hu | A Joint Model for Nonlinear Longitudinal Data with Informative Dropout[END_REF][START_REF] Björnsson | Performance of Nonlinear Mixed Effects Models in the Presence of Informative Dropout[END_REF]. Recently the Stochastic Approximation Expectation-Maximization (SAEM) algorithm, a method relying on an "exact" calculation of the likelihood, was extended to include time-to-event data [START_REF] Vigan | Evaluation of estimation methods and power of tests of discrete covariates in repeated time-to-event parametric models: application to Gaucher patients treated by imiglucerase[END_REF][START_REF] Mbogning | Joint modelling of longitudinal and repeated timeto-event data using nonlinear mixed-effects models and the stochastic approximation expectation-maximization algorithm[END_REF] in Monolix and NONMEM.

Here we evaluated the benefit of joint models using the SAEM algorithm for characterizing the relationship between survival and a biomarker having a non-linear kinetics. We compared by simulation the precision and the type 1 error of longitudinal and survival parameters obtained using a joint, a joint sequential and a two-stage model in the context of a clinical study in mCRPC according to the strength of the association between PSA kinetics and survival.

Models and notations

A Mechanistic model for PSA kinetics

In absence of treatment we assume that prostatic cells, C (mL -1 ), proliferate with rate r (day -1 ) and are eliminated with rate d (day -1 ). PSA (ng.mL -1 ) is secreted with a production rate p (ng.day -1 ) and cleared from the blood with rate δ (day -1 ). We suppose that a chemotherapy for mCRPC acts by blocking cell proliferation with time-varying effectiveness, e(t), and hence the proliferation rate under treatment is given by = 1with 0 ≤ ≤ 1 (Figure 1):

= 1 - - = - (1)
Treatment is initiated at t=0, PSA(0)=PSA0 and C(0)=C0 are PSA value and the number of prostatic cells at treatment initiation respectively. Here, treatment is assumed to be constantly effective until a certain time, Tesc, after what tumor escapes and treatment has no longer an effect:

= ≤ ! "#$ 0 > ! "#$ (2)
Further, we made the assumption of quasi steady-state at treatment initiation and thus

& = '× ) *
. With this piecewise constant treatment effect (2), the model ( 1) has an analytical solution given by:

, , = ' ) -./0 / 1' -./0 / + 3 & - ' ) -./0 / 1' 4 /' ≤ ! "#$ ' ) -/ 1' -/ /-05 678 + 3 ! "#$ - ' ) " 9 :;< ;= > 678 -/ 1' 4 /' /5 678 > ! "#$ (3)
Because only 4 parameters can be identified from Eq. 3 ,we fixed d to 0.046 day -1 , corresponding to a half-life of tumor cells of 15 days, consistent with an apoptotic index of 5% in metastatic prostate cancer [START_REF] Tu | Incidence of apoptosis and cell proliferation in prostate cancer: Relationship with TGF-β1 and bcl-2 expression[END_REF]. Moreover we fixed δ to 0.23 day -1 , corresponding to a PSA half-life in blood of about 3 days [START_REF] Polascik | Prostate specific antigen: a decade of discovery--what we have learned and where we are going[END_REF]. Thus PSA kinetics was defined by the vector parameter ψ={r, PSA0, ε and Tesc}.

Statistical model for PSA measurements

Let yij denote the j th longitudinal measurement of log(PSA+1) for the individual i at time tij, where i=1, …, N, j=1, …, ni, N is the number of subjects and ni the number of measurements in subject i. The nonlinear mixed-effect model (NLMEM) for PSA is defined as follows:

@ AB = log AB , , A + 1 + F AB (4),
where PSA is given by the formula (3), ψi is the vector of the individual parameters and eij the residual error which follows a standard normal distribution with mean 0 and variance 1. The vector of the individual parameters ψi is decomposed as fixed effects µ={r, PSA0, ε, Tesc} representing median effects of the population and random effects ηi specific for each individual. It is assumed that ηi∼N(0, Ω) with Ω the variance-covariance matrix. In this work, Ω is supposed to be diagonal. Each diagonal element ωq 2 represents the variance of the q th component of the random effect vector ηi. We assumed log-normal distribution for r, PSA0 and Tesc:

log ψ H,A = log I H + η H,A
and logit-normal distribution for ε:

KLM A = KLM μ 0 + η 0,A with KLM O = log P Q ./Q R for 0<x<1.
The population parameters vector of PSA noted θl is composed of {µ, Ω, σ}.

Statistical model for survival

Let Xi denote the time to event and Ci the censoring time for the i th subject. Survival data (Ti, δi) are observed in all individuals, where Ti=min(Xi, Ci) and δ T = 1, if X T ≤ C T , 0 otherwise. For the event process, we used a hazard function of the form:

ℎ A | , , A = ℎ & exp c , , A (5)

Joint model

Joint models assume conditional independence: given the random effects ηi, longitudinal measurements and survival events are independent. All parameters, f = {f h , f # } are simultaneously estimated. Thus the joint log-likelihood for subject i can be written as follow [START_REF] Rizopoulos | Fully exponential Laplace approximations for the joint modelling of survival and longitudinal data[END_REF]:

K A f = log j @ A |k A ; f mℎ A ! A |k A ; f ' n A ! A |k A ; f o k A ; f k A (6)
where

A |k A ; f = exp P -j ℎ & p|k A ; f exp c p, , A &
pR is the survival function conditionally on the random effects, @ A |k A ; f the density of the longitudinal observations conditionally on the random effects and k A ; f the density of the random effects.

Two-stage model

In order to simplify the heavy calculations involved by Equation ( 6) one may also use a two-stage approach. In the first step PSA kinetics parameters (θl) are estimated assuming complete independence of PSA kinetic and survival and the Empirical Bayes Estimates (EBEs), defined as the mode of the conditional distribution , A |@ A , f q h , are used to provide individual parameters, noted , q A . In the second step, the survival parameters (θs) are estimated maximizing the usual log-likelihood

K f # = ∑ KLM sℎ A ! A t , , q A ; f # ' n A ! A t , , q A ; f # u v Aw.
. This method is analogous to the sequential method called "Individual Pharmacokinetic

Parameters" (IPP) used in pharmacometric field to handle PharmacoKinetic/PharmacoDynamic (PKPD) data [START_REF] Zhang | Simultaneous vs. sequential analysis for population PK/PD data I: best-case performance[END_REF].

Joint sequential model

In order to reduce the number of parameters to estimate in Equation ( 6), an alternative consists in first estimating population PSA kinetic parameters, as done in the two-stage model, and then estimating parameters related to survival (θs) fixing the all population PSA parameters (θl) in Equation ( 6) to the values obtained at the previous stage. This method, inspired from the "Population PK parameter and individual PK data" for the combined analysis of PKPD data, has been shown to limit the bias compared to two-stage approach [START_REF] Zhang | Simultaneous vs. sequential analysis for population PK/PD data I: best-case performance[END_REF].

Simulation study

Design

Simulation setting was inspired by one arm of a phase III study of clinical development of chemotherapy for metastatic prostate cancer [START_REF] Tannock | Aflibercept versus placebo in combination with docetaxel and prednisone for treatment of men with metastatic castration-resistant prostate cancer (VENICE): a phase 3, double-blind randomised trial[END_REF]. M=100 datasets with N=500 patients were simulated with PSA measurements every 3 weeks for 2 years (i.e., the last possible measurement time was at t=735 days), leading to a maximum of 36 observations per patient (Table I). Follow-up was censored at t=735 and no other mechanism than death was considered for dropout. For the simulation of the time to death, k was fixed to 1.5, and 3 values for β were considered: 0, 0.005 and 0.02, corresponding to 'no link', 'low link' and 'high link' between PSA kinetics and survival, respectively. In order to maintain a comparable amount of PSA measurements across scenarios, λ was determined in each scenario such that the probability of survival at the end of the follow-up (i.e., 735 days) was equal to 25% with the median PSA kinetic parameters (Table I), leading to λ=580, 765 and 2150 in scenarios 'No link', 'Low link' and 'High link', respectively (Table II). Lastly, we evaluated the effects of having both a large baseline risk and a strong effect of PSA kinetics by setting β=0.02 and λ=580 in the scenario called 'Short survival'. Figure 2 shows the survival functions for these 4 scenarios for the "median patient", i.e., a virtual patient having PSA kinetic parameters equal to the median values in the population.

In order to take into account the effect of withdrawals from PSA follow-up, we also explored additional scenarios where PSA and/or vital status were censored in case of PSA progression defined as an increase of 25% above the nadir and of at least 2 ng/ml compared to nadir (see supplementary file 1).

All simulations were carried out with the R software version 3.0.1 [START_REF]R: A language and environment for statistical computing[END_REF].

Parameter estimation

The estimation of two-stage, joint sequential and joint models was performed for each SAEM was run using 1 chain and we verified that using 3 chains, as suggested in a related context [START_REF] Vigan | Evaluation of estimation methods and power of tests of discrete covariates in repeated time-to-event parametric models: application to Gaucher patients treated by imiglucerase[END_REF], gave similar results. CPU (Central Processing Unit) times for parameters estimations and -2LL estimations were recorded on a i7 64bits 3.33GHz.

Evaluation criteria

We used Relative Estimation Errors defined by: xyy f q z = { | } ;{ * { * × 100, where f * and f q z are the true and estimated parameters, respectively, for dataset m, m=1…M. Boxplots of the REEs with the 10% and 90% percentiles were plotted. When β=0 (scenario 'No link'), the boxplot of the absolute estimation error, c • d , with the 10% and 90% percentiles were plotted .

The type 1 error and power were calculated as the proportion among the M datasets for which LRT (called in the following "uncorrected LRT") led to reject the null hypothesis H0:

β=0. The type 1 error was evaluated in the scenario 'No link' and the power was calculated for the 3 other scenarios. The significance level of the tests α for the observed type 1 error was fixed to 0.05, leading to a 95% prediction interval for 100 replicates equal to [0.7%-9.3%].

In some cases the estimation of -2LL, which relies on a stochastic approximation, was associated with a non-negligible standard error. Because this can lead to an inflation of the type 1 error, we also evaluated a "corrected LRT". In this test H0 was rejected if

-2•• ' & + 2

Results

Simulated data

Figure 3 shows the spaghetti-plots along with the Kaplan-Meier curves of one typical dataset for each of the 4 scenarios. Because the scenario 'No link' assumes that death does not depend on PSA kinetics, PSA rebound after loss of treatment efficacy (at time Tesc) was more frequently observed than in the 3 other scenarios. As expected (see methods), the numbers of measurements in the first 3 scenarios were largely similar (Table III). In the last scenario where both the baseline hazard function and the effect of PSA kinetics were large, early events frequently occurred and the total amount of PSA data was much smaller.

Estimation performance

No bias was observed in the scenario 'No link' regardless of the approach. In the twostage approach, increasing effect of PSA on survival led to higher levels of bias (Figures 4 and5). In particular there was a systematical underestimation of the PSA effect on survival with median (Q1;Q3) REE for β equal to -8.4% (-12.6 ; -4.1), -14.8% (-18.9 ; -10.2) and -9.1% (-16.7 ; -5.7) in scenarios 'Low link', 'High link' and 'Short survival', respectively. The bias was corrected by using joint sequential models or joint models, with median (Q1;Q3) REE for β of 0.005% (-3.6 ; 5.3), -0.6% (-3.3 ; 2.9) and 0.03% (-4.8 ; 5.7) in scenarios 'Low link', 'High link' and 'Short survival', respectively for this latter method.

Although the three approaches led to low REEs for the almost all parameters of PSA kinetics (Figure 4), a bias was observed for the proliferation rate of tumor cells, r, with median (Q1;Q3) REE equal to -0.4% (-0.7 ; -0.05), -0.8% (-1.0 ; -0.5) and -1.2% (-1.8 ; -0.7) in scenarios 'Low link', 'High link' and 'Short survival', respectively, when using the two-stage or joint sequential approach. Here as well, the bias was largely reduced when using a joint model, with median (Q1;Q3) REE for r equal to 0.01% (-0.4 ; 0.3), -0.004% (-0.3 ; 0.2) and -0.08% (-0.6 ; 0.5), in scenarios 'Low link', 'High link' and 'Short survival', respectively. Of note large REE were found for the parameters λ and k (|REE|>30%) in the scenario 'High link' when using joint and joint sequential models, due to the presence of a local extremum of the likelihood function.

Lastly we also considered additional scenarios where PSA data and/or vital status were censored in case of PSA increase (see supplementary file 1). Although the precision of the parameter estimates was deterioriated due to the reduction in the amount of data available no substantial bias in the PSA kinetic parameters was found. However bias was found in survival related parameters, in particular when both PSA and vital status were censored after disease progression and this bias systematically led to an overestimation of the hazard function.

Test performance

The uncorrected LRT led to a type 1 error of 21%, 9% and 12% for the joint model, the joint sequential model and the two-stage model, respectively, i.e., outside the 95% prediction interval ([0.7%-9.3%] for 100 replicates). The use of a corrected LRT (see methods) led to a smaller type 1 error of 4%, 3% and 12% for the joint model, the joint sequential model and the two-stage model, respectively. The reason why the type 1 error

for the two stage model with or without correction were similar is due to the fact that the standard error of -2LL were negligible with this model (<10 -4 ). For the scenarios with β≠0, the power was 100% with all three models, regardless of the correction.

Computation time

Mean CPU times for the simultaneous estimation of the 12 parameters using joint model were about 5 times larger than the total CPU times using two-stage model (70 vs 14 minutes) and about 1.2 times larger than the total CPU times using joint sequential model (70 vs 59 minutes), ignoring time for specific data manipulation required for setting the two-stage and joint sequential approaches. Mean CPU times for the -2LL estimation using joint model (respectively joint sequential model) and 100,000 chains was about 3.1 (respectively 3.6) times larger than when using the joint approach and 20,000 chains (264 vs 86 minutes (respectively 207 vs 57 minutes)) but led to a mean se-2LL(H1) of 1.96 vs 5.14 (respectively 2.40 vs 5.90).

Discussion

Numerical complexities have long limited the use of joint models to longitudinal processes defined by linear mixed-effect models [START_REF] Wu | Analysis of Longitudinal and Survival Data: Joint Modeling, Inference Methods, and Issues[END_REF][START_REF] Taylor | Surrogate markers and joint models for longitudinal and survival data[END_REF][START_REF] Henderson | Joint modelling of longitudinal measurements and event time data[END_REF]. Here we evaluated by simulation, in the context of PSA and survival in metastatic prostate cancer, the capability of a new feature of the Stochastic Approximation Expectation-Maximization algorithm in Monolix to estimate the parameters of a joint model where the longitudinal process was defined by a nonlinear model. And we compared the results to two simplified approaches, two-stage and joint sequential models.

We found that joint model provided unbiased parameters of both longitudinal and survival processes. In contrast, the use of a two-stage model [START_REF] Proust-Lima | Determinants of change in prostate-specific antigen over time and its association with recurrence after external beam radiation therapy for prostate cancer in five large cohorts[END_REF][START_REF] Taylor | Individualized predictions of disease progression following radiation therapy for prostate cancer[END_REF] led to large biases when PSA kinetics and survival were linked. In particular, the impact of the biomarker kinetics on the survival, as measured by the link parameter β, was systematically underestimated, consistent with results found in linear mixed-effect model [START_REF] Sweeting | Joint modelling of longitudinal and time-to-event data with application to predicting abdominal aortic aneurysm growth and rupture[END_REF][START_REF] Ibrahim | Basic Concepts and Methods for Joint Models of Longitudinal and Survival Data[END_REF]. Beside survival parameters, a bias on the tumor proliferation rate, r, which is the driving force for the increase in PSA, was also observed in scenarios with β≠0. The fact that no such bias occurred when using joint model shows that the simultaneous estimation of the hazard function also improved the estimation of the longitudinal parameters. Moreover, a twostage approach led to an inflation of type 1 error (i.e., conclude to an effect of PSA on survival while there is none) which could be explained by the shrinkage of the EBEs in patients with short survival [START_REF] Ribba | The Use of Model-Based Tumor-Size Metrics to Predict Survival[END_REF]. By construction the joint sequential model led to the same biases on PSA longitudinal parameters than the two-stage model, but the estimation of survival parameters was close to that obtained with the joint model. This, therefore, suggests that joint sequential model could be a relevant approach when joint model cannot be performed.

In spite of the increasing numerical capability, the likelihood of joint models remains particularly complex to calculate. Here we reported that the likelihood was estimated with a relatively large uncertainty. Increasing the Monte-Carlo sizes led to smaller standard errors of the likelihood but considerably increased the computation time. The impact of this error on type 1 error was in part accounted by using a corrected likelihood ratio test (LRT). However more studies will be needed to precisely determine when this correction is necessary and whether it can be improved. Here for instance the corrected rejection region did not take into account the covariance between the likelihood calculated under the null and alternative hypotheses. Although the Wald test may be an alternative, we found here that standard errors of the estimates tended to be smaller than the Root Mean-Squared Errors (RMSE), indicating a potential underestimation of the standard errors.

Furthermore, and in spite of the stochastic algorithm, the estimation of parameters related to survival was complicated in some cases by the existence of local extremum of the likelihood function. This stresses the need, in practice, to perform several runs of likelihood maximization using different initial values.

The main advantage of nonlinear models is the possibility to develop physiological models based on nonlinear differential equations, which naturally integrate the correlations between the different biomarkers. In this study, we used a rather simple model where the treatment effectiveness was piecewise constant, which allowed us to derive a biexponential analytical solution for the PSA kinetics. However this model may clearly be over-simplistic and more complex models will be needed that rely on several markers, such as tumor size or drug pharmacokinetics. The facilitated use of these models via joint models holds the promise that the determinants of survival may be much better characterized [START_REF] Mbogning | Joint modelling of longitudinal and repeated timeto-event data using nonlinear mixed-effects models and the stochastic approximation expectation-maximization algorithm[END_REF].

Regarding the survival model, we restricted here to a rather simple fully parametric model, where the baseline hazard function was a Weibull model [START_REF] Yu | Joint longitudinal survival cure models and their application to prostate cancer[END_REF] and the hazard function was related to the current PSA values. In practice complex survival models could be evaluated and standard tools for model selection (e.g., AIC or BIC) could be used to evaluate the effect of various transformations of the biomarker, such as the derivative or the cumulative value of PSA. Lastly with a fully parametric model the prediction and the simulation of the individual hazard function can easily be performed, making possible to guide treatment adaptation in a dynamic manner [START_REF] Ribba | A Review of Mixed-Effects Models of Tumor Growth and Effects of Anticancer Drug Treatment Used in Population Analysis[END_REF].

Conclusion

SAEM algorithm implemented in Monolix was shown to provide precise estimates for joint models where the longitudinal model was defined by a non-linear mixed-effect model. This opens the way for a more systematic use of joint models and a better understanding of the relationship between biomarker kinetics and survival, especially in the field of metastatic cancer where survival and non-linear biomarker kinetics are intrinsically related. tends to be underestimated. These trends led to an overestimation of the hazard function and hence an underestimation of the survival function.

Conclusion

Drop out caused by predefined levels of PSA progression does not affect the estimation of the parameters associated with PSA kinetics.

Regarding survival parameters, a bias towards an overestimation of the hazard function may occur, in particular when not only PSA but also the vital status is not collected after disease progression.

1

  Nonlinear mixed-effect models for prostate-specific antigen kinetics and link with survival in the context of metastatic prostate cancer: a comparison by simulation of two-stage and joint approaches Solène Desmée a,b,* , France Mentré a,b , Christine Veyrat-Follet c , Jérémie Guedj a,b a INSERM, IAME, UMR 1137, F-75018 Paris, France. b Université Paris Diderot, IAME, UMR 1137, Sorbonne Paris Cité, F-75018 Paris, France. c Drug Disposition, Disposition Safety and Animal Research Department, Sanofi, Chilly-Mazarin, France

  where the baseline hazard function, h0, is a Weibull hazard function ℎ β measures the strength of the association between the PSA kinetics and the risk of death. If β=0, the survival process is independent on the PSA evolution and survival data can be fitted by a Weibull model without adjusting for PSA. If β≠0, the survival process depends on the PSA kinetics. The survival parameters to estimate are θs={λ, k, β}.

  dataset and each scenario using the Stochastic Approximation Expectation-Maximization (SAEM) algorithm in the software Monolix version 4.2.2.The initial values of the parameters were those used for the scenario 'No link'. Minus twice log-likelihood (-2LL) was calculated by Importance Sampling, fixing the Monte-Carlo sizes to achieve a sufficient level of precision for Likelihood Ratio Test (LRT) to 100 000 Monte-Carlo sizes for the scenario 'No link', 20 000 for the other scenarios in joint model and 2 000 in two-stage model.

Figure 1 :

 1 Figure 1: Schema of the secretion of PSA by prostate and cancer cells. PSA is expressed in ng.mL -1 and C in mL -1 . r is the rate of prostatic cells proliferation in absence of treatment (day -1 ), d the rate of prostatic cells elimination (day -1 ), p the rate of PSA secretion by C (ng.day -1 ), δ the rate of PSA elimination (day -1 ) and e(t) the timedependent treatment effect.

Figure 2 :Figure 3 :Figure 4 :

 234 Figure 2: Typical evolution of PSA(t) (solid black) and survival functions in the typical patient (who have the fixed effects of the Table I as PSA parameter) for the scenarios 'No link' (β=0, λ=580) (solid orange), 'Low link' (β=0.005, λ=765) (dashed green), 'High link' (β=0.02, λ=2150) (dotted blue) and 'Short survival' (β=0.02, λ=580) (dotdash purple)

Figure 5 :

 5 Figure 5: Boxplots of the relative estimation errors for parameters related to survival (in % except for β of the scenario No link for which estimated values are represented) for two-stage model (blue), joint sequential model (purple) and joint model (red), for the 4 scenarios. Top left: scenario No link (β=0, λ=580), top right: scenario Low link (β=0.005, λ=765), bottom left: scenario High link (β=0.02, λ=2150) and bottom right: scenario Short survival (β=0.02, λ=580).

Figure S1 :

 S1 Figure S1: Spaghetti-plots (black lines) and estimated Kaplan-Meier curves (colored solid lines)with their 95% confidence interval (colored dashed lines) for one typical dataset (N=500) for each scenario, without withdrawal (red curves), with withdrawal after PSA progression (pink curves) and with withdrawal and censor after PSA progression (grey curves).

Figure S2 :

 S2 Figure S2: Boxplots of the relative estimation errors for the parameters related to PSA for joint model without withdrawal (red), with withdrawal (pink) and with withdrawal and censor (gray) and for the 3 scenarios. Top: scenario No link (β=0, λ=580), middle: scenario High link (β=0.02, λ=2150) and bottom: scenario Short survival (β=0.02, λ=580).

Figure S3 :

 S3 Figure S3: Boxplots of the relative estimation errors for the parameters related to survival (in % except for β of the scenario No link for which estimated values are represented) for joint model without withdrawal (red), with withdrawal (pink) and with withdrawal and censor (gray) and for the 3 scenarios. Top: scenario No link (β=0, λ=580), middle: scenario High link (β=0.02, λ=2150) and bottom: scenario Short survival (β=0.02, λ=580).

  •• ' . was larger than ƒ .

	ƒ . " , i.e., for a significance level of 5%, p /"ˆˆ ' & to 2.	" or p /"ˆˆ ' .	" non negligible compared
	" + … † ‡p /"ˆˆ ' & 2LL(H0) and se-2LL(H1) are the estimated standard error of -2LL under H0 and H1, " + p /"ˆˆ ' . " ; ∞ where -se-
	respectively, whereas ƒ . " and … † are the chi-squared value with 1 degree of freedom and the α th quantile of the standard normal distribution, respectively.
	‡se /"ŠŠ H &	" + se /"ŠŠ H .

"

is the uncertainty for the sum of the two estimated -2LL. We used a corrected LRT if … † ‡p /"ˆˆ ' & " + p /"ˆˆ ' . " was non negligible compared to

Table I :

 I Values of the population PSA parameters used for the simulations in all

	scenarios
		Fixed	Transformation	Inter-individual
		effects		standard deviation (ω)
	r (day -1 )	0.05	log-normal	0.1
	PSA 0 (ng.mL -1 )	80	log-normal	0.6
	ε	0.3	logit-normal	1.5
	T esc (day)	140	log-normal	0.6
	σ	0.36	-	-

Table II :

 II Values of the population survival parameters used for the simulations of the

	4 scenarios
	Scenario No link	Scenario Low link	Scenario High link	Scenario Short survival
	β	0		0.005	0.02	0.02
	λ (day)	580		765	2150	580
	k	1.5		1.5	1.5	1.5
	Table III: Number of PSA measurements per patient and median survival in the total
	number of simulated (50000) patients for the 4 simulated scenarios
	Number of	Scenario No	Scenario Low	Scenario High	Scenario Short
	PSA	link		link	link	survival
	measurements
	1-5	7%		7%	8%	29%
	6-10	12%	13%	10%	20%
	11-20	26%	31%	22%	26%
	21-35	30%	29%	21%	17%
	36	24%	21%	39%	8%
	Median survival (day)	457	414	552	217

Acknowledgements:

The authors would like to thank Drug Disposition Department, Sanofi, Paris which supported Solène Desmée by a research grant during this work. We also thank Hervé Le Nagard for the use of the computer cluster services hosted on the "Centre de Biomodélisation UMR1137".

Supplementary file 1: Impact of withdrawal from PSA follow-up on joint estimation

It is frequent in clinical trial protocols that treatment is stopped when a disease progression (increase in PSA or tumor size, adverse events) is observed. When treatment is stopped, the patient may drop out of the study. Although the vital status may continue to be collected, the PSA measurements are no longer recorded in the study.

Simulation framework

For the sake of simplicity we consider here that a disease progression was only due to a PSA progression defined as an increase of 25% above the nadir and of at least 2 ng/ml compared to nadir. PSA data were removed accordingly in all datasets of the scenarios 'No link', 'High link' and 'Short survival' (see main analysis), leading to a dramatic decrease in the number of PSA measurements (Table S1).

In order to assess the impact of withdrawal data, two cases were considered:

The vital status is known at the end of the study (scenarios 'Withdrawal')

The vital status is censored at the time of the disease progression (scenarios 'Withdrawal + censor') Thus, in the first case the number of observed deaths is equal to that observed in the main analysis, and in the second case the number of observed deaths is much smaller that observed in the main analysis (scenarios 'No withdrawal'). This results in much larger confidence interval for the Kaplan-Meier curves (Figure S1).

Results

The variability of the parameter estimates increases when patients withdrawal from PSA follow-up (Figures S2 andS3) which was expected because there is a smaller number of PSA measurements. PSA kinetic parameters (Figure S2) were not affected by withdrawal, with or without censor of vital status. However all three parameters related to survival were estimated with a bias in case of censor of survival (Figure S3): β and k tend to be overestimated while λ