F El

B Ducourthial
email: bertrand.ducourthial@utc.fr

A distributed algorithm for path maintaining in dynamic networks

Keywords: Ad hoc, dynamic, path maintaining

Routing becomes obsolete in ad hoc dynamic networks. Path maintaining becomes necessary in order to maintain a communication that already started between two entities. In this paper we present a path maintaining algorithm.

I. INTRODUCTION AND RELATED WORKS

Ad hoc dynamic networks represent a challenging domain of application due to their specifications. Still we find many applications on these networks nowadays, like the vehicular networks, drone networks or even pedestrian networks. The general method to study these networks starts by studying their dynamics. The dynamic changes are closely related to the frequency of neighborhood changes, and the functioning and requirements of the protocols.

Unicast communications in these networks require a continuous communication between the source of the messages and the destination even if they are separated by multiple hops. Many routing protocols exist for mobile networks, like AODV, OLSR and geographic routing among others. But these protocols are not efficient if the dynamic of the network increases to exceed the admitted dynamicity. Not to forget that these protocols require broadcast in general, location services [5] [4] or infrastructure bases, which make them inadequate to highly mobile networks. We should also mention that the need for global knowledge in these protocols increases the control over the network, in order to build or to update the structures needed to maintain routes.

II. CONTRIBUTION

Due to their specificities, dynamic networks do not require routing as those used in networks with fixed topologies or low dynamics. In fact, in mobile networks, the search for a distant destination might be obsolete since the nodes are frequently moving, meaning that the destination might have changed its location by the time the source receives its response. The search for the destination implies the broadcast of messages in order to identify its position. And in case some geographic protocols admit the knowledge of the position of the destination, this means that a location service has already identified this position using broadcasted messages. As explained in [START_REF] Ducourthial | Vehicular Networks: Techniques, Standards and Applications, chapter Routing in Vehicular Networks: User Perspective[END_REF], the need for unicast communication is in order to maintain a communication that started when the source and the destination were neighbors, and that is needed to pursued for a certain duration. This problem is called path maintaining. This said, the aim of the path maintaining In this paper, we describe the path maintaining algorithm, that we denote PTH. PTH is a path maintaining algorithm that relies on local adjustments of the path. Local adjustment is used in order to avoid having a global knowledge of the network, which implies to flood the network with too much control messages in order to build a global knowledge that might become unusable because of the dynamic. PTH adjusts the path between the source and the destination using neighbor nodes of the broken links in the path. Starting from a direct communication between the source and the destination, PTH interferes when these two entities move apart, and the direct communication between them becomes impossible. At this point, the neighbor nodes of the broken link are used to relay the messages. The same mechanism is used for all the broken links of the path between the source and the destination. PTH relies on three mechanisms: local periodic update for the nodes of the path only, path reduction and path extension. These mechanisms are detailed in the next section.

III. THE PTH ALGORITHM

In this section, we describe our algorithm named PTH for solving the path maintaining problem. It is mainly based on three mechanisms, that we describe in this section: local periodic update, path extension and path reduction.

The first mechanism -local periodic update -allows to deal with neighborhood changes and failures. It relies on periodic diffusion of messages in the neighborhood of the sender. These messages contain some local information regarding the path. Such information is composed by the list of members of the path (eg. u 0 u 1 u 2 u 3 . . . ) (see Figure 1), some flags allowing to determine the sender and the willing receiver of the current message (u 0 u 1 >u 2 u 3 if u 1 is the sender and u 2 the receiver) and an uncertainty flag regarding a member of the path (u 0 u 1 >u 2 ?u 3 (see Figure 1) if u 1 has a doubt on its successor u 2 ). Such a message informs both the predecessor and the successor of the local state of the path, which in turns can then update their own information. Fig. 2: Extension of the path through u6 and reduction through u7

Other nodes not belonging to the path may propose to belong to, in order to repair or shorten it.

The second mechanism -path extension -allows to deal with link breaking. This can appear when two neighbors go far each other (Consider Figure 2, with u 0 ✏ u i , u 1 ✏ u j and u 6 ✏ v for instance). Consider that the link ru i , u j s in the path breaks. As the node u i sends periodically some messages containing u i >u j , it expects implicit acknowledgment of u j , that is messages without uncertainty, containing u i u j >. This means that u j receives the message of u i and forwards it with the path u i u j >. If it does not receive such messages from u j , it sets the uncertainty flag on its successor u j in its next messages: u i >u j ?. Either u j receives messages of u i with an uncertainty flag on itself (communication u i Ð u j broken) or it does not receive at all messages from u i (communication u i Ñ u j broken). In both cases, it will set the uncertainty flag on its predecessor u i in its messages; they will contain: u i ?u j >. Such uncertainty flags allows to neighbors of both u i and u j to propose repairing the path. If a neighbor node v notices such exchanges, it counts the received messages from u i and u j . When a given threshold is reached, v proposes to be relay of the communication by sending u i ?v>u j ?. As several neighbors of both u i and u j may propose to be a relay, u i (closer from the source) chooses the first (say v) and sends u i >vu j ?. Then v sends u i v>u j ?. Then u j sends u i vu j > and the path is repaired (to the condition that a node v was present in the neighborhood of the breaking edge extremities).

The third mechanism -path reduction -consists in reducing the path when possible. This can be done by a node in the path, or neighbor of the path. Consider the case when the reduction between two given nodes u i and u j (where u i precedes u j in the path) can be done by a node v, neighbor of the path (Consider Figure 2, with u 2 ✏ u i , u 5 ✏ u j and u 7 ✏ v for instance) . This node v, by receiving the messages sent by u i and u j simultaneously, observes that it can reduce the path by being a relay between u i and u j .

The proposition of the reduction is done by placing in the path the shortcut denoted by u i -?v-?u j (with the uncertainty flag on the links ru i , vs and rv, u j s). The message sent by v is of the form: . . . u i -?v-?u j . . . v>u j . . .. When u j receives this message, it confirms to v the possibility of reduction, removing the uncertainty on the reduction link rv, u j s. The node v then asks the permission of u i to be a relay. At this point, u i sends a validation message . . . u i -v-u j > . . . u j . . . to its successor in the path; this message will be relayed until reaching u j .

Indeed, as several overlapping reductions may occur simultaneously, the reduction u i ✁ v ✁ u j has to be validated by all nodes from u i to u j in the path. This allows to avoid any split of the path into several smaller disconnected paths. If a node is already engaged with another reduction, it will not forward the validation message containing the reduction. In the converse case, the node forwards the message and becomes engaged. By this way, in case of two reductions in conflict for a common sub-path, the validated reduction is the one that first sent a validation message into the common subpath. When u j receives the validation message, it confirms the reduction by relaying from now messages of v instead of messages of its old predecessor u j✁1 . An engaged node will either leave the path or receive a message without reduction from its predecessor; it stops then being engaged. The same process is used when the reduction is proposed by nodes u i belonging to the path instead of a neighbor node.

IV. PTH VALIDATION AND PERFORMANCES Whatever are the performance of a given algorithm, the dynamic of the network can lead to failure because it could compromise any communication. Our protocol is able to run even in highly dynamic network but the following requirement is necessary: a neighbor of the path is present during the path extension. This operation is very short (few local messages). By the way, we have a contract between the dynamic and the specifications of our protocol. This has been formalized in [START_REF] Ducourthial | Best-effort group service in dynamic networks[END_REF] under the term of best effort algorithm. A best effort algorithm does its best regarding the dynamic while still ensuring some useful properties for those (users or other protocols) relying on it. More precisely, whenever a topological property is fulfilled, a continuity property is ensured. Here, the topological property is the presence of a neighbor node when two nodes belonging to the path move far each other. The continuity property is the existence of the path from source to destination, the two initiators which were in the same neighborhoods at the beginning. Proof is omitted by lack of place.

PTH has been compared to a basic geographic routing with a location service, and to a traditional broadcast in the same scenario under the Airplug emulator [START_REF] Buisset | Vehicular networks emulation[END_REF] (with 31 cars moving from the UTC laboratory to the train station in Compiègne), and starting from the same initial state. Note that the Airplug emulator creates a link between two nodes if they are in the range of each other. Consider now N the number of messages sent by the source node in the network. While the broadcast flooded the network with 8.4✂N messages, the geographic routing with its location service sent to the network 5✂N messages, and PTH sent 2.4✂N messages. Not to mention that when 31 cars were involved in sending messages for the broadcast or geographic routing, only 6 were involved when running the PTH algorithm.

Fig. 1 :

 1 Fig. 1: Local periodic messages application is to maintain a communication initiated with a path of length 1 and to avoid the flooding of the network with unnecessary messages.In this paper, we describe the path maintaining algorithm, that we denote PTH. PTH is a path maintaining algorithm that relies on local adjustments of the path. Local adjustment is used in order to avoid having a global knowledge of the network, which implies to flood the network with too much control messages in order to build a global knowledge that might become unusable because of the dynamic. PTH adjusts the path between the source and the destination using neighbor nodes of the broken links in the path. Starting from a direct communication between the source and the destination, PTH interferes when these two entities move apart, and the direct communication between them becomes impossible. At this point, the neighbor nodes of the broken link are used to relay the messages. The same mechanism is used for all the broken links of the path between the source and the destination. PTH relies on three mechanisms: local periodic update for the nodes of the path only, path reduction and path extension. These mechanisms are detailed in the next section.


J Maysonnave

N Jukam

M S M Ibrahim

K Maussang

J Madéo

P Cavalié

P Dean

S P Khanna

D P Steenson

E H Linfield

A G Davies

J Tignon

S S Dhillon

An integrated injection seeded THz source and amplifier for time-domain spectroscopy

A terahertz (THz) frequency quantum cascade laser (QCL) is used as an integrated injection seeded source and amplifier for use in THz time-domain spectroscopy. A THz input pulse is generated inside a QCL, by illuminating the laser facet with a near-infrared pulse from a femtosecond laser, and amplified using gain switching. The THz output from the QCL is found to saturate upon increasing the amplitude of the THz input power, which indicates that the QCL is operating in an injection seeded regime.

In the technique of terahertz (THz) frequency timedomain spectroscopy (TDS), THz radiation is generated and detected using femtosecond (fs) near-infrared laser pulses, enabling measurement of both the THz amplitude and phase [1]. In TDS systems, the THz radiation can be generated when the near-infrared fs laser illuminates a GaAs photo-conductive antenna [2], travels through an electro-optic crystal with a non-vanishing χ χ χ χ 2 [3], or is focused in air [4]. In all these cases, the THz field amplitude scales linearly with the power of the fs pulse, until saturation takes place. One strategy to increase further THz field amplitudes is to use higher fs pulse energies, and TDS systems that utilize mJ pulse energies are becoming increasingly common [5]. Although this is a promising laboratory-based technique, it is not practical for applications outside the laboratory owing to the large cost and size of regenerative amplified laser systems.

An alternative approach to generate higher THz fields is to amplify THz waves directly after generation, and hence enable low-power fs laser pulses to generate high THz wave amplitudes. THz frequency quantum cascade lasers (QCLs) are natural candidates for THz amplifiers, and have already been used as external THz amplifiers to measure the QCL gain. [6][7][8]. In the steady-state, external amplification is limited by gain clamping and depends on the facet reflectivity [9]. Gain switching with RF pulses can be used to unclamp the gain in the QCL and augment external pulse amplification [10]. Amplifying THz 'seed' pulses in QCLs with sufficiently long RF pulses [11] can lead to coherent injection seeding where the QCL emission is phase-locked to the fs laser. This enables phase-resolved detection of the QCL emission in the timedomain, and permits the use of QCLs as intense THz sources for TDS. However, if the THz seed pulses are generated by external photoconductive antennas, the THz must be coupled from free space into the QCL cavity. This introduces large coupling losses that are associated impedance mismatch between the cavity and free space and can negate the effect of THz amplification.

In this letter, injection seeding of a QCL is achieved with THz seed pulses that are generated directly inside the QCL cavity. This results in a completely integrated QCLbased source for TDS. Specifically the THz seed pulses are generated inside the QCL cavity [12] by illuminating one of the facets with a near-infrared fs laser beam (Fig 1a). This removes the need to use a photoconductive THz emitter to generate the THz seed pulses and parabolic mirrors to couple the THz seed pulses into the cavity (Fig 1b). Gain switching of the QCL is used to achieve large amplification of the internally generated THz seed pulses. A coupled cavity scheme allows the amplitude of the input seed pulse to be increased without affecting the QCL gain [13,14]. We find that for sufficient THz seed amplitudes, the amplified seed pulses saturate the QCL gain, which indicates that injection seeding takes place via integrated seed generation.

To enter the injection seeding regime, the amplitude of the THz pulse generated at the facet must be sufficiently large to prevent the QCL from being 'seeded' by amplified spontaneous emission. Since the THz pulse amplitude generated at the facet increases with applied voltage [12], it is therefore desirable to apply a large voltage across the facet. However, QCL operation ceases once the applied bias becomes too large owing to misalignment of the injector and upper level laser state. In order to decouple the facet voltage from the QCL bias voltage, focused ion beam (FIB) etching was used to remove a 20 µm wide portion of the gold contact and the heavily-doped n-GaAs contact layer on the top of the laser ridge. This splits the QCL cavity into a short 305 µm seeding section used as the THz pulse generator, and a long 2.5 mm QCL gain section for THz pulse amplification. The resistance between these two sections (~35 Ω) is several times larger than the QCL differential resistance (3-6 Ω). Although, the two sections are not completely electrically isolated; removing the top contact in this way eliminates the need to etch through the entire active region using reactive ion etching [13,14]. As shown in Fig. 1d, independently biasing the seeding section decreases the QCL output power. This is most likely due to the leakage current between the seeding and QCL section and increased THz losses in the seeding section. The QCL is based on a bound-to-continuum design, and processed into a single plasmon waveguide with a lateral dimension of 180 µm and a total cavity length of 2.85 mm. The QCL is soldered to a gold-plated copper mount and placed in a continuous flow cryostat. Measurements are taken at 10 K, and laser emission is centered at 2.5 THz.

Before the arrival of the fs pulse (80fs, 808nm, 6nJ) that generates a THz pulse in the seeding section, the gain section is biased below threshold. When the THz pulse is generated in the QCL, an RF bias pulse (triggered by the fs laser) is applied to the gain section. This places the QCL in a transient state where the gain is much greater than the clamped gain, and permits large amplification [10]. Fig. 1c shows a schematic diagram of the electronic arrangement. A fast photodiode generates the RF pulses when illuminated with the fs laser. The RF pulses are amplified by a pre-amplifier that is operated in the saturation regime to produce RF pulses with a relatively flat top. The RF pulses are subsequently amplified by a power amplifier and applied to the QCL. The power of the incident RF pulses (Fig. 1e) is ~6 W, and about 40% of the RF power is injected into the QCL. Faster electronics permit shorter RF rise times and pulse durations compared with studies of external injection seeding [11]. A bias tee also allows the QCL gain section to be biased with a quasi-DC voltage (10 kHz), which reduces the RF power necessary to drive the QCL above threshold. The quasi-DC bias is set to ensure that the RF pulses drive the QCL to the bias at which maximum gain occurs (i.e. just before misalignment of the QCL band-structure). The seeding section is biased at 3.8V (~180A/cm 2 ) which roughly corresponds with Jmax in Fig. 1d. The RF pulses and QCL gain section are modulated at 10kHz (25% duty cycle) while the seeding section is modulated at 20 kHz i.e. at twice the duty cycle of the QCL gain section and RF pulses modulation. This permits lock-in detection of the difference field, which removes the unamplified low frequency components of the THz signal. Fig. 2 shows the QCL output when the RF drives the QCL above threshold. After the initial THz pulse is generated in the seeding section, it traverses the laser cavity and experiences gain (near the laser frequency) and losses (at other frequencies). At the opposite facet, part of the THz pulse is reflected back into the cavity and part is transmitted out of the QCL. This process will then continue with multiple passes traveling through the cavity. The output of the QCL thus consists of several THz pulses separated by the round-trip time (~71 ps) of the cavity. A pair of parabolic mirrors collimates and focuses the transmitted THz pulses onto a 200-µm-thick <110> ZnTe crystal for electro-optic detection.

As shown in Fig. 2a, the THz pulses undergo large amplification when the RF pulse brings the QCL bias above threshold and unclamps the gain. Figs. 2b and2c are zoomed in portions of the 1st and 4th THz pulses in Fig 2a, that show the phase-resolved nature of the measurement in Fig. 2a. After three round-trips the difference field is amplified by more than a factor of 80, and the output field is almost two orders of magnitude larger than the input field. The amplified THz emission lasts for approximately the same time as the RF pulse duration in Fig. 1e. Since there is no significant reflection between the seeding section and the gain section, no secondary THz seed pulses are produced. Although later THz pulses undergo dispersion, the THz pulses remain ) RF pulses are created with a fast photodiode (PD), and amplified. An electronic delay line is used to vary the RF pulse arrival time. The RF pulse train is modulated with a 50 Ω switch, and the pulse amplitude can be varied with a variable attenuator. A bias tee allows a quasi-DC voltage to be applied to the QCL along with the RF. A 20dB pickoff tee (RF probe) allows the RF shape to be monitored. d) d) d) d) Lightcurrent density (V-J) plots for the device with the seeding section biased at 0V (black), 3.8V (~180A/cm 2 ) (red), and shorted to the QCL section (blue). e) e) e) e) The RF pulse sent to the QCL measured with the pick-off tee on an 8 GHz sampling oscilloscope (50Ω). distinct. The maximum peak-to-peak field (40 V/cm corresponding to an intensity of 1.8 W/cm 2 ) is significantly greater than studies of external injection seeding on a 2.1THz QCL [11], and is due to the higher output powers of the 2.5THz devices (~20mW) compared to the 2.1THz device (1.5mW). From the ratio of the spectral amplitudes of successive THz pulses in Fig. 2a, we can find the average difference between the unclamped gain and the clamped gain, which we define as the excess gain. A positive excess gain will result in a net amplification of a pulse that undergoes a round-trip through the QCL cavity. The largest value of the average excess gain (at the laser frequency) is 9 cm -1 and occurs between the 2 nd and 3 rd pulses in Fig. 2a.

To determine if the THz input pulses saturate the QCL gain (and are thus injection seeding the QCL), the output QCL field can be studied as function of the input THz pulse amplitude by varying the voltage applied to the seeding section. The peak-to-peak fields of the 1st, 5th and 6th output THz pulses are plotted in Fig. 3 as a function of the seeding section voltage. The 1st output THz pulse corresponds to a single pass through the cavity. Although the THz radiation generated at the facet cannot be directly measured, it is proportional to the amplitude of the 1st emitted THz pulse. The amplitude of this pulse increases almost linearly for seeding section voltage less than 3.5 V. For higher voltages, the input amplitude continues to increase with seeding section voltage although the slope decreases slightly. When the seeding section voltage (and hence the amplitude of the generated THz pulse) is small, the peak-to-peak field of the 5th and 6th pulses also increases with voltage. However, for large seeding voltages the peak amplitudes of the 5th and 6th pulses are flat even though the amplitude of the 1st pulse keeps increasing. This indicates that the gain of the laser is saturated (clamped) by the amplified THz pulses, and the laser emission has entered the injection seeded regime.

In conclusion, we have demonstrated an integrated QCL-based source of THz radiation suitable for TDS. THz pulses are generated directly inside a coupled-cavity QCL by illuminating the facet with fs near-infrared laser pulses, and are subsequently amplified to high field values using gain switching until injection seeding of the QCL is achieved. The THz signal generated in the seed element is thus increased by amplifying the THz wave using the high gain available from the QCL gain section, rather than by increasing the fs laser power. Decoupling the strength of the THz signal from the fs laser power could make TDS more practical by reducing the need for higher power fs lasers.

Figure 1

 1 Figure 1 a) a) a) a) THz pulses are generated inside the QCL by illuminating the seeding section with an fs laser. b) b) b) b) THz pulses created by an external photoconductive antenna are coupled into a QCL with parabolic mirrors. c) c) c) c) RF pulses are created with a fast photodiode (PD), and amplified. An electronic delay line is used to vary the RF pulse arrival time. The RF pulse train is modulated with a 50 Ω switch, and the pulse amplitude can be varied with a variable attenuator. A bias tee allows a quasi-DC voltage to be applied to the QCL along with the RF. A 20dB pickoff tee (RF probe) allows the RF shape to be monitored. d) d) d) d) Lightcurrent density (V-J) plots for the device with the seeding section biased at 0V (black), 3.8V (~180A/cm 2 ) (red), and shorted to the QCL section (blue). e) e) e) e) The RF pulse sent to the QCL measured with the pick-off tee on an 8 GHz sampling oscilloscope (50Ω).

Figure 2

 2 Figure 2 a) a) a) a) The THz difference field emitted from the QCL measured with electro-optic sampling. The incident RF pulse amplitude is 6 W and the quasi-DC bias is 62 A/cm 2 . b) b) b) b) Enlarged view of the 1st THz pulse that undergoes a single pass through the QCL. c) c) c) c) Enlarged view of the 4th THz pulse, which shows the phase-resolved nature of the measurement.

Figure 3

 3 Figure3Maximum peak-to-peak (p-p) fields of the 1st (black), fifth (green) and sixth (blue) THz pulses versus the voltage applied to the seeding facet. For values of the seeding voltage >4 V, the amplitudes of the fifth and sixth THz pulses saturate, while the amplitude of the 1st THz pulse continues to increase.

Acknowledgements

Acknowledgements Acknowledgements Acknowledgements This work was supported by ANR projects "HI-TEQ", "THINQE-PINQE", ERC Advanced Grant projects "NOTES" and "TOSCA", the EPSRC (UK), and the MARA Agency (Malaysia).

References References References


Laurent Romary

Maud Medves

TEI-based representation of the PEER metadata profile 1

The proposed structure combines a global structure (<TEI> 2 ), which can potentially integrate any information that can be found in a full-text representation of a paper article, and a sub-structure (<biblStruct> 3 ) that specifically contains the bibliographical information of the article. This allows us to process in a uniform way the two following scenarios:

1

Introduction

In the context of rapid growth of institutional repositories, the PEER project (www.peerproject.eu) has been set up to monitor the effects of systematic archiving of author's final peer-reviewed manuscript over time.

To conduct this research, interoperability between editor's data and online repositories is an essential asset. It is therefore important to specify the encoding scheme of required metadata elements, particularly the ones related to author's identification (as it is particularly important for citations, e.g. databases such as the ones accessed through Web of Science).

A high granularity of metadata is preferable, as it allows for deeper structured information and enables precise information to be identified and shared. It offers indeed greater flexibility in treating each data field in isolation if required.

The PEER project has adopted the Text Encoding Initiative encoding scheme (www.teic.org). This document describes the output interchange that was tuned for the PEER Depot for the integration and distribution of the metadata information provided by publishers within the PEER project. It is based on the TEI's Guidelines for Text Encoding and Interchange (P5), with some additional constraints intended to make the corresponding information structures univocally interpretable.

 The PEER Depot receives full-text articles in XML (or retrieves them from repositories such as PMC) and converts them to the TEI format, thus exploiting all its expressive capacities.

 The PEER Depot receives specific metadata information, with possibly some additional content (e.g. abstract). A highly simplified <TEI> structure is created, which is mainly a container for disseminating the bibliographical content.

The remaining part of this document will primarily address the second scenario, which is the one needed for the research to be carried out within the PEER project.

General structure of a TEI document

The TEI information model is intended to represent both the textual content of a document and the metadata attached to it. This is reflected in the two main parts of a <TEI> root element, namely <TEIHeader> and <text>.

The TEI header is in turn organised in a series of sub-components:

 <fileDesc> gathering the main characteristics of the document (title, author, bibliographic description of the source)

 <profileDesc> providing some information about the content (e.g. languages used in the text, keywords)

 <revisionDesc> providing the history of the document

The <text> element is further decomposed in <front>, <body> and <back>. Where available, abstracts are represented in <front> and full-text content in subsequent elements.

Skeleton of a full TEI document (as relevant for PEER) for the representation of scholarly articles

Representation of bibliographical information

The representation is based on the TEI <biblStruct> element, which is organised as follows:

<biblStruct type="article"> <analytic> … </analytic> <monogr> … <imprint> … </imprint> </monogr> … </biblStruct>
A <biblStruct> is mainly divided into two sub-structures:

 <analytic> to indicate the bibliographical characteristics of an article (title and authors)

 <monogr> to account for the publication details of the journal (journal name, publisher information, ISSN, etc.). It contains in turn an <imprint> element which gathers publication and/or distribution aspects of the article in the corresponding journal (pagination, volume, issue, etc.) When applicable, additional notes or identifiers can follow, for instance, the DOI, pubmed-central-id or repository-specific-id will appear here:

<biblStruct type="article"> <analytic>…</analytic> <monogr>…</monogr> <idno type="pmid">12345678</idno> </biblStruct>

The <analytic> element

The title of a journal article is represented by means of the <title> element (with appropriate @level attribute) as follows:

<title level="a">Multilocus Analysis of Age Related Macular Degeneration</title> When necessary, a further @type attribute may be used to differentiate between main and subtitles (@type="main" vs. @type="sub").

Each author in the <analytic> element is independently described by means of an <author> element. This element contains the author's name, affiliation and addresseswhen available -as presented in the outline below: <author> <idno type="...">...</idno> <persName> <forename>Michael</forename> <surname>Dean</surname> </persName> <affiliation>…</affiliation> <email>dean@ncifcrf.gov</email> </author>

For more details about encoding the affiliation element, see the chapter "Dealing with affiliation" below.

The <monogr> element

The <monogr> element gathers journal identification information (journal title and ISSN) together with the publishing information contained in its <imprint> sub-element, for instance: <monogr> <title level="j" type="main">European Journal of Human Genetics</title> <title level="j" type="nlm-ta">Eur J Hum Genet</title> <idno type="ISSN">1018-4813</idno> <imprint>…</imprint> </monogr>

The <imprint> element "By imprint is meant all the information relating to the publication of a work: the person or organization by whose authority and in whose name a bibliographic entity such as a book is made public or distributed (whether a commercial publisher or some other organization), the place of publication, and a date. It may also include a full address for the publisher or organization. Full bibliographic references usually specify either the number of pages in a print publication (or equivalent information for non-print materials), or the specific location of the material being cited within its containing publication." 4 The <imprint> element is organised as follows:

<imprint> <pubPlace>Oxford</pubPlace> <publisher>Clarendon Press</publisher> <date type="Published" when="1969-02-07"/> <biblScope type="vol">3</biblScope> <biblScope type="issue">2</biblScope> </imprint>

The possible values for the attribute type on <biblScope> are the following:

 vol: volume  issue: issue  fpage: first page  lpage: last page
 pp: number of pages when the information about full pagination is not available 5 The possible values for the attribute type on <date> are the following:

 Published: date of publication (online or imprint -when no further precision is available)6

 ePublished: date of online publication (when available)

 pPublished: date of imprint publication (when available)

<biblStruct> skeleton

The following example provides an overview of the full internal structure of the <biblStruct> element as provided by the PEER Depot within a <TEI> document. Most mandatory PEER metadata fields are illustrated here.

Mapping table

The following table makes explicit the PEER mandatory metadata fields, as found in the TEI based exchange format transferred to PEER repositories.

Field Name Path in TEI document Notes

Article title /TEI/teiHeader/fileDesc/sourceDesc/ biblStruct/analytic/title[@type='main']

When applicable additional titles are provided (with specific values of @type).

Correspond

Dealing with affiliations Element <author>

It contains the information about the author, personal or corporate, of an article. It groups three elements: the name of the author (<persName>), the affiliation (<affiliation>) and the email address.

Ex.:

<author>

Element <affiliation>

The <affiliation> component of <author> is intended to contain any potentially relevant information with regard to the author's academic situation: research group, laboratory, institution. It contains an informal description of the author's present or past affiliation with some organization, for example an employer or a sponsor.

It groups two elements: the name of the organization (<orgName>) and its postal address (<address>).

Ex.:

<affiliation> <orgName type="institution">Technische Universität Darmstadt</orgName> <orgName type="department">Institute of Materials Science</orgName> <address> <addrLine>Petersenstraße 23</addrLine> <postCode>D-64287</postCode> <settlement>Darmstadt</settlement> <country key="DE">Germany</country> </address> </affiliation>

We have identified three types of organizations, which correspond to the three-tiered system of WoS.

-Institution: corresponds to the global structure that hosts the author (can be a university or an institute (e.g. MIT, INRIA)) -the largest scale of organization type.

-Department: corresponds to a specialized division of the institution mentioned above -intermediate structure of organization type (department, faculty, institute) if there is one. -Laboratory: corresponds to the research team or group, which the author belongs to (e.g. Joint Research Laboratory Nanomaterials) -the smallest scale of organization type.

Element <address>

It contains the postal address of the organization, which the author is affiliated to.

Ex.:

<address> <addrLine>Chemin du Solarium</addrLine> <addrLine>BP20</addrLine> <postCode>33175</postCode> <settlement>Gradignan</settlement> <country key="FR">France</country> </address>

Here are the different elements that can be used to describe the address.

 <addrLine> contains one line of a postal address. It can be used as many times as needed (in case of a multiple line address).  <postCode> contains a numerical or alphanumeric code used as part of a postal address to simplify sorting or delivery of mail.  <settlement> contains the name of a settlement such as a city, town, or village identified as a single geo-political or administrative unit.  <region> contains the name of an administrative unit such as a state, province, or county, larger than a settlement, but smaller than a country.  <country> contains the name of a geo-political unit, such as a nation, country, colony, or commonwealth, larger than or administratively superior to a region and smaller than a bloc. The key attribute must be used to identify the country, according to ISO 3166 a2.

Complex cases

Multiple institutions or multiple departments a) This case typically corresponds to the affiliation of a joint laboratory.

Use the @key attribute to identify the different institutions (or departments), which the joint laboratory belongs to.

Example: Joint Research Laboratory Nanomaterials, which is a joint laboratory of the Technische Universität Darmstadt and the Karlsruhe Institute of Technology. <affiliation> <orgName type="laboratory">Joint Research Laboratory Nanomaterials</orgName> <orgName type="institution" key="instit1">Technische Universität Darmstadt</orgName> <orgName type="institution" key="instit2">Karlsruhe Institute of Technology</orgName> <address> <addrLine>Petersenstrasse 23</addrLine> <postCode>D-64287</postCode> <settlement>Darmstadt</settlement> <country key="DE">Germany</country> </address> </affiliation> b) In the case of a laboratory described by several names (that is often the case for the UMRs of French CNRS), use the same procedure.

Example: GREMI, also named UMR 6606 (a joint laboratory of CNRS and Université d'Orléans) <affiliation> <orgName type="laboratory" key="lab1">GREMI</orgName> <orgName type="laboratory" key="lab1">UMR 6606</orgName> <orgName type="institution" key="instit1">CNRS</orgName> <orgName type="institution" key="instit2">Université d'Orléans</orgName> <address> <addrLine>14, rue d'Issoudun</addrLine> <addrLine>BP 6744</addrLine> <postCode>45067</postCode> <settlement>Orléans cedex 2</settlement> <country key="FR">France</country> </address> </affiliation> c) In an even more complex case, where several departments belonging to different institutions can be found, a @corresp attribute is used to identify which superior structure each inferior unit belongs to. The @corresp attribute expresses a correspondence between the organisation and its parent structure, identified by the attribute xml:id. Please note that when no @corresp attribute is used, it is implied that the laboratory belongs to the next superior structure (full distributivity).

Ex.1: Dipartimento di Fisica belongs to the Università di Trento, whilst Gruppo Collegato di Trento belongs to the INFN. <affiliation> <orgName type="department" key="dep1" corresp="#org01">Dipartimento di Fisica</orgName> <orgName type="department" key="dep2" corresp="#org02">Gruppo Collegato di Trento</orgName> <orgName type="institution" key="instit1" xml:id="org01">Università di Trento</orgName> <orgName type="institution" key="instit2" xml:id="org02">Istituto Nazionale di Fisica Nucleare</orgName> <address> ... </address> </affiliation> Ex.2: IHCP is a department of the Joint Research Center, which is a department of the European Commission. <affiliation> <orgName type="department" key="dep1" corresp="#org03">IHCP</orgName> <orgName type="department" key="dep2" xml:id="org03">Joint Research Center</orgName> <orgName type="institution">European Commission</orgName> <address> ... </address> </affiliation> 7 Ex.3: IGFAE is a joint research department of USC and Xunta de Galicia while Departamento de Fisica de Particulas is a department of USC. <affiliation> <orgName type="department" key="dep1" corresp="#org04 #org05">IGFAE</orgName> <orgName type="department" key="dep2" corresp="#org04">Departamento de Fisica de Particulas</orgName> <orgName type="institution" key="instit1" xml:id="org04">USC</orgName> <orgName type="institution" key="instit2" xml:id="org05">Xunta de Galicia</orgName> <address> ... </address> </affiliation> Ex.4: Nancy I Poincaré is an institution belonging to a larger institution, Nancy Université. <affiliation> <orgName type="department" key="dep1">Institut Jean Lamour</orgName> <orgName type="department" key="dep1">UMR 7198</orgName> 7 In this case, it is implied that the Joint Research Center belongs to the only institution (European Commission). There is no need to use the @corresp attribute. <orgName type="institution" key="instit1" corresp="#org06">Nancy I Poincaré</orgName> <orgName type="institution" key="instit2" xml:id="org06">Nancy Université</orgName> <address> ... </address> </affiliation> 8

Default value -Published is used when no further precision about online and imprint publication are associated to a given date.

Metadata profile adopted within the PEER project (ECP-2007-DILI-537003) 2 http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-

Several affiliations

The case is encountered when an author provides two affiliations (the current one and the one he wants to see appearing on the paper, which often corresponds to his past affiliation when he conducted the research that led to the article). Use the attribute "current" to identify the current affiliation.

Example:

<author> <persName> <forename>B.</forename> <surname>Bastin</surname> </persName> <affiliation> <orgName type="laboratory">LPC Caen</orgName> <orgName type="institution" key="instit1">ENSICAEN</orgName> <orgName type="institution" key="instit2">Université de Caen Basse-Normandie</orgName> <orgName type="institution" key="instit3">CNRS/IN2P3</orgName> <address> <postCode>14050</postCode> <settlement>Caen</settlement> <country key="FR">France</country> </address> </affiliation> <affiliation type="current"> <orgName type="laboratory">GANIL</orgName> <orgName type="institution" key="instit4">CEA/DSM</orgName> <orgName type="institution" key="instit3">CNRS/IN2P3</orgName> <address> <postCode>14076</postCode> <settlement>Caen</settlement> <country key="FR">France</country> </address> </affiliation> 8 In this case, it is implied that the Institut Jean Lamour, also identified as UMR 7198, belongs to the next superior structure (instit1 -Nancy I Poincaré).

</author>

Several geographical addresses

For lack of encountered examples, this case will not be treated as such here. Cases exist though and relate to laboratories, which are bilocalized and therefore have a double address for a single laboratory.


Lionel Bertaux
email: lbertaux@laas.fr

Pascal Berthou
email: berthou@laas.fr

Thierry Gayraud
email: gayraud@laas.fr

Paul D Amer
email: amer@cis.udel.edu

GEO-LOCALIZATION TO ENHANCE SCTP HANDOVER IN PUBLIC TRANSPORTS BETWEEN SATELLITE NETWORKS AND WLAN

Keywords: geo-localization, handover, mobility, multi-homing, public transports, SCTP

The rise of new ways of communication along with the spread of mobile Internet will encourage the evolution of public transports to provide uninterrupted Internet service to its customers. It is obvious that using multiple technologies such as Wi-Fi, 3G and satellite each with their own characteristics will enhance the connectivity. Current proposals for mobility are mainly based on the use of proxies and need the modification of the infrastructure. The multi-homing feature included in SCTP allows roaming without losses and without interrupting the session. This study focuses on the use of geo-localization to improve SCTP handover, and shows how it can be implemented and what improvements can be done.

Introduction

Recent significant growth in mobile technologies along with the development of Internet services has increased the needs of travelling customers. In an "always connected" world, public transports (trains, busses, planes, etc.) have to offer more services to their users (emails, timetables, multimedia streaming, etc.) and also Internet access to company databases for data backup, real-time traffic information, etc. Having contiguous connectivity involves the use of several access technologies. This study considers the two main ones compatible with public transports constraints of cost, mobility, broadband, etc.: satellite networks and wireless terrestrial access points. To enhance the vertical handover between these two technologies, we propose to exploit known characteristics of the public transports: predetermined travel routes and geo-localization using on-board GPS and odometers.

Handovers (vertical or horizontal) impact communications at multiple layers. Network and below layers are concerned by handover since they are responsible of connecting to Access Points (APs) and reaching remote hosts. But the most impacted layer could be transport layer. Sessions are bound to transport connections or associations. If a connection goes down, the session fails and the application will need to establish a new session. To avoid such failures, network layer solutions provide uninterrupted connectivity to transport layer, but these solutions' requirements can be fairly high in term of architecture modifications or mandatory mechanisms. In this paper, we choose to focus on SCTP, a transport protocol that can provide mobility through its multi-homing feature and its extensions.

The first part of this paper introduces the context of public transport with their characteristics and their mobility scheme. The second section presents existing mobile IP solutions, and explains why transport mobility solutions are a credible alternative. In part three, the proposed solutions are depicted with a time analysis of the handover and a brief description of the implementation. The fourth part includes the test scenario, the results and their analysis to demonstrate the enhancements that can be done to the handover delay with SCTP. The last part concludes with an evaluation of the proposed solution and a statement of future work.

Mobility in Public Transports

This section introduces public transports listing their key characteristics and describing their mobility schemes. A short description of conceivable access technologies is also provided.

Context

Public transports are going to evolve and provide more services to customers. One challenge is to have a continuous Internet connection onboard. To design a mobile network architecture fitted for public transports, it is essential to understand their characteristics:

 Vehicles have a fixed run, thus their localization is known,  Network traffic is composed of flows with different requirements (low delay, large bandwidth, connectivity, etc),  Vehicles are equipped with multiple communication technologies,  There is a need for autonomous network configuration.

Knowing vehicle run and its localization can help to predict mobility. Our proposition is to use a "map" that lists all available networks along a vehicle's run to predict handovers based on current vehicle localization. An autonomous mobility solution based on this map will be detailed in section 4.

An Internet connection onboard a public transport would have several uses: backup data from the vehicle operator, critical information related to vehicle, web traffic and even VoIP. Such flows have different QoS (Quality of Service) requirements and priority levels. The access point choice should be done according to these requirements and restrictions should be applied if all requirements cannot be met. Communications can also be enhanced in case several networks are available: depending on their characteristics they can provide lower delay, higher bandwidth or larger coverage. Influence of network characteristics is detailed in section 2.2.

When changing access network, latency is introduced by a layer 2 handover and the network configuration. Therefore, performing a handover should be done only if necessary (i.e. if the handover enhances communications) and at the right time. Example: if a mobile node is connected to 3G and heads toward a Wi-Fi AP, performing a handover will be useful only if the node spends more time in range of the Wi-Fi than the latency introduced by handover. In addition, the handover method used needs to be taken into account: it defines the latency introduced by handover and it also impacts on communications efficiency. This matter is treated in section 3.

Communication Technologies

In public transport networks, several communication technologies are available. Since each technology has its assets and its downside, the physical and data Link layers will affect communications differently. Network efficiency depends on the following parameters: available bandwidth, end-to-end delay, QoS provided and service availability. Besides network characteristics, technology operating cost can be taken into account; providers can charge depending on data exchanges.

For information purposes, Table 1 presents parameter values for three communication technologies: Wi-Fi, 3G/UMTS and satellite communication network. Instead of considering such characteristics independently, it is important to keep a global view of available supports. An example is given by [SOR 2009] based on Diesel-Net experimentations. Even if Wi-Fi has a higher bandwidth than 3G, a larger global throughput is achieved on 3G due to its overall availability. But since users will be charged depending on data exchanges, it can be useless to use 3G permanently for non-critical applications.

Bandwidth

Solutions for mobile networks

As explained in section 2, public transports can keep communications alive by connecting to multiple networks but in most cases, changing the access network modifies the IP address of the node. Since transport protocols use the IP address and port to identify a node, communications can break during handovers. Many solutions have been proposed to improve mobility and avoid session failure.

Current Solutions

Since changing IP address is an issue for transport protocols, propositions have been made for TCP to support mobility. TCP-Migrate [SNO 00] uses an extra id negotiated between hosts during connection initiation. If mobile node changes its IP address, remote host will be able to identify TCP session thanks to the extra id. Another solution is MPTCP (MultiPath TCP [RFC 6182]); a transport protocol designed according Next Generation Transport recommendations. It consists in a layer above multiple simple TCP connections allowing using multiple networks simultaneously.

Most propositions to support mobility are located at network layer. [RFC 3344] -Now obsolete by [RFC 5944] -adds mobility support for IPv4 by the use of a Home Agent (HA) and a tunnel between Mobile Node and HA. Main issue of this solution is the triangular communication introduced between MN and Corresponding Node (CN) to route data from Home Address (HoA) to Care-of Address (CoA) attributed in the new network.

Solution proposed by Mobility Support in IPv6 [RFC 6275] uses the same mechanisms for IPv6 plus a "Binding Update" (BU) that allows the update of IP address used for communication and thus to communicate directly between Mobile Node (MN) and Corresponding Node (CN) after an authentication (in a mobile context, authenticate remote host is obviously mandatory for security reasons). Fast Handover for Mobile IPv6 (FMIPv6) defined in [RFC 5568] is one of the most interesting solution based on IPv6, it allows to pre-configure IP address before changing link by defining two entities : the Previous Access Router (PAR) and the New Access Router (NAR). This solution is oriented on inter-domain mobility. For intra domain mobility, a Hierarchical Mobile IPv6 (HMIPv6) defined in [RFC 5380] proposes the use of a Mobility Anchor Point (MAP) to avoid exchanges with the HA when changing access point in the same domain. However, for inter-domain mobility this solution introduced extra exchanges to configure the MAPs. Another solution called Proxy Mobile IPv6 (PMIPv6) proposes to handle mobility in the network with new entities: Local Mobility Anchor (LMA) and Mobile Access Gateway (MAG). MN is no longer aware of mobility and has a fixed Home Network Prefix. All data is tunnelled between LMA and the MAG where MN is connected; propositions have also been made to avoid tunnelling when CN and MN are on the same link. IETF working group Network Mobility (nemo) is an extension of MIPv6 and allows sessions continuity for all nodes in the mobile network. It proposes to apply MIPv6 solutions to Mobile Router (MR) and thus defining necessary exchanges.

These solutions are interesting since they can provide transparent mobility for applications and ameliorations provided to MIPv6 allows reducing handover latency. However they all modify network architecture by adding new entities (HA, PAR, NAR, MAP ...) and some of them even add an overhead with extra headers or tunnelling. Moreover, as QoS support or multicast support, mobility support should be difficult to deploy in different admin domains. We have the conviction that in a near future these solutions will not be available in a large and heterogeneous context. The convergence between a satellite operator, a 3G provider and a private Wi-Fi network is a complex task that will take decades.

Stream Control Transmission Protocol (SCTP)

SCTP is an IP transport protocol that includes all TCP features: reliability, order delivery, flow control and congestion avoidance. Its first standard was written in 2000; the protocol is now defined by [START_REF] Stewa | 1rt, Stream Control Transmission Protocol[END_REF]. Main features introduced by SCTP are:

 Multi-streaming: allows creation of several streams in only one association (SCTP connection),  Multi-homing: enables use of multiple network interfaces simultaneously.

By using several network interfaces, hosts define multiple paths between them and one is considered primary. If a timeout occurs, a packet is retransmitted on the secondary path. When several timeouts occur in a row, the primary path is considered unavailable and a secondary path becomes the primary. Extensions have been developed to dynamically add IP addresses, thus allowing mobility for SCTP (see section 3.3).

SCTP has been designed for terrestrial links. Studies have been made on SCTP's behaviour over satellite communication networks (showing it can perform as well as TCP [BER 10, SHA 03].

SCTP extensions for mobility

Thanks to multi-homing, SCTP can connect to multiple networks. An SCTP extension defined in [RFC 5061] allows dynamic IP addresses configuration, meaning that during an association's lifetime, addresses can be added or removed and primary path can be changed. If multi homed, a mobile node is thus able to establish connection with a new network, add the new IP address to association and choose the new network as the primary path. This way, a handover can be performed without breaking the transport connection and without triangular communications.

For security reasons, this extension needs to be used with [RFC 4895] that allows chunk authentication so that no third party can generate requests to add new IP or change primary path. These extensions and SCTP together are called mSCTP (mobile SCTP). SCTP mobility has been compared with network layer mobility scheme (see [SIV 05] and [KIM 08]) and results show that it can reduce handover latency and even improve throughput while performing handover compared to mIPv6 mobility.

If mSCTP enables mobility support, it only provides API (Application Programming Interface) to application developers. There is no automatic handover sequence. [KIM 06] presents an algorithm mSCTP-DAC (mobile SCTP-Dynamic Address Configuration) to make handovers as fast as possible:

 When connecting to a new network, a node requests an IP address,  New IP address is added to association and communicated to remote host along with a request to change the primary path,  Heart Beat (HB) is sent on new path to check its availability,  New path becomes primary once it is available for both hosts. Data is now sent on the new path.

To evaluate handover, a key delay is the time spent between network detection and its use as the primary path. The time needed to add an IP address and check path availability is fixed (bounded??) by the network RTT (Round Trip Time) since acknowledgments have to been taken into account. But delay introduced by first step (i.e. getting a new IP address) will depend on the method used and on hardware configuration. Dynamic Host Configuration Protocol (DHCP) is used in most networks to configure new nodes interfaces and introduces delay due to information exchanges. In the next section, a solution based on static IP address will be presented and compared with the above algorithm.

Using localization to avoid failover

Behaviour

Public transports can be easily localized via GPS and odometers. The solution introduced in this section puts together localization and a "map" of all available networks along vehicle run in order to improve multi homed SCTP handover.

When a public transport has to go inside the range of a known access point, it can be expedient to establish connection and use it as primary path during the time spent in its range. By knowing access points geographic position, a mobile node can anticipate handover by configuring a network interface in advance and sending its new IP address to remote hosts (via SCTP Add-IP requests). Besides localization, other factors have to be taken into account:

 In case several networks are available, choose the best fitted one based on parameters introduced in 2.2,  Determine interest of handover: depends on time spent in range and associations states. If at least one association is active and handover is necessary, the following sequence is performed:

 "Network map" advertises a new AP will soon be available and handover will be needed,  Network interface is configured (start-up, network settling, IP address modification and route rules setting),  Local host adds new IP address in association and sends Add-IP request to remote host,  When the new network is detected, mobile node connects, sends a heart beat on new path and the request Change-Prim-Addr on old path.  Upon acknowledgment receipt, new path can be used as primary.

Anticipating connection to a new access point allows configuring network interface and to adding the new IP address before handover and thus reducing the handover latency. Next sub-section analyzes this behaviour by describing exchanges needed between nodes for this approach.

Temporal Analysis

Main point of this analysis is to demonstrate in a logical way that the use of this solution is more efficient than a standard handover with mSCTP and therefore will be compared with mSCTP-DAC. Here are the abbreviations used in the analysis : Fig. 1 presents time necessary for handover with the two methods. Chunks ASCONF and HB can be sent at the same time, their position has been chosen here for reading purpose only. To consider handover effective, both hosts have to consider the new path as available: even if one node can emit on new path when receiving requests, we will take into account delivery time of acknowledgments. It has also to be noticed that in these graphs the CN is not multi homed: according to RFC it is not mandatory, only MN needs to be multi homed.

[1]

[2] Equation [1] express handover time if heart beat is sent by mobile node along with ASCONF request, on contrary if CN is sending heart beat after receiving request a one-way delay is added [2]. Our solution can be expressed in two ways, by starting handover time at the beginning of configuration sequence ( ) or by starting it when network is detected ( ):

[3] [4] For our solution to be effective and [3] to be true, the network interface has to be configure, the IP address sent to remote host and acknowledge before network detection. The minimal time needed for these actions can be deducted from [3] and [4]:

[5] Expressions based on RTT: This solution is interesting since it allows decreasing handover time by at least and at best 30% of total time. An important point of this analysis is the minimal time needed before network detection, proposed solution will only be efficient if [5] is verified. It is also noticeable that mSCTP is sending one more control message when network is detected, thus ASCONF chunks are grouped in the same SCTP packet and their size is small enough to ignore sending time compared to propagation time.

Experiments

Scenarios

The proposed solution has been checked on a test-bed composed of four nodes: two APs, one MN and one fixed CN. One access point is a Wi-Fi gateway and will help in emulating mobility by switching off/on the access network. The other access point is SATEM, a satellite link emulator that emulates connection to a communication satellite network. Both nodes are multi homed and connected on one path by satellite link and on the other path by Wi-Fi link.

To illustrate mobility, MN is connected to satellite link when association is initiated and Wi-Fi link is down. When MN detects Wi-Fi AP, connection is established and handover is performed. Application generates data at 50 kilo-Bytes per seconds with 500 Bytes packets size. Two handovers algorithms are compared: mSCTP-DAC and our solution.

Results and analysis

This section presents the measurements done on the platform. Both algorithms have been used with the above scenario several times to compare their behaviour and efficiency. Last results show the impact of multiple handovers on communications.

Fig. 2 (a) and (b) present application delay when performing a handover between satellite link and Wi-Fi link. In Fig. 2 (a), it can be seen that IP is added to association before connection to network while in Fig. 2 (b) can be added only after connection to network. When connected to network, Heart Beat is sent also faster with our solution and thus allows to perform handover faster. This is due to the time needed for route configuration and establishment: an additionnal latency is introduced between IP address configuration and HB emission (i.e. link avaibility).

With DAC algorithm, the IP is configured and added to association 20ms after connection to network. In the experiments we didnot use any DHCP server and IP addresses are configured in a static way. If a DHCP server is used, additionnal latencie is introduced as configuration time (see 4.2). In order to evaluate the differences between the two solutions, experiments have been run ten times. Table 2 presents average handovers latencies when performing handover. On the global delay between connection to the new network and emission of data chunks on the new path, our solution enhance handover by 900ms (corresponding to 13 meters at 50KMph). In this experiment, data was generated at 100 kilo-Bytes per seconds and there were no bandwidth limitation. Changes on global throughput when performing handover is limited by SCTP multi-homing : since congestion window is computed for each path, it can restart where it stops and no time is loss when going back on satellite network. In satellite networks, "slow-start" phase lasts several seconds and limits application throughput at start. Above results shows that SCTP handover can be improved with our solution by reducing the latency between network detection and link avaibility.

Conclusion and Perspectives

In order to guarantee network connectivity onboard, a public transport needs to resolve transport layer connexions breaks while performing handovers. Many solutions have been conceived at network layer as well as at transport layer, but few have been implemented. Indeed most of them use additional entities or functionalities that cannot be deployed in nowadays networks due to their architecture or private administration. Our solution focuses on transport layer and uses SCTP multihoming features along with localization to predict handovers and perform them faster.

Results obtained from experiments verify expected enhancement from temporal analysis. It can save some time by pre-configuring network interfaces. By reducing handover time, more time spent in range of access point can be used for communications. In a public transport network, impact can be consequent since handovers can happen frequently with mid-range technologies (such as Wi-Fi).

Further studies will be dedicated to use this solution along with network layer solutions based on mobile IP: instead of having a static address, the mobile node could use our "network map" to request a new IP before network detection (as done in FMIPv6). Implementation also needs some improvements concerning "network map" to automate handover prediction, this map could be generating from a real bus lane by detecting available networks along its path.

These experiments were done using SATEM; a SATellite EMulator developed by ASTRIUM and real Wi-Fi access points. Implementations and tests with a real Operating System helped in defining configurable protocol parameters and accessible network information. This information can be used to configure a network simulator according to real-world possibilities. Making tests on a simulator will allow increasing the number of access points and simulating mobility between them.

   -Time needed to configure network interface (depends on method used and hardware configuration,  -End-to-end delay between two hosts on path i,  -Round Trip Time on path i,  -time when network is detected,  -begin of configuration sequence,  -Time needed by mSCTP to fully perform handover,  -Time needed by our solution to fully perform handover from starting time .  -Chunk ASCONF/ASCONF-Ack emission,  -Chunk HB/HB-Ack emission. Handover time that will be study is time spent between new network detection and data sent on new path.

Fig. 1 -

 1 Fig. 1 -Exchanges needed to perform handover with SCTP.Fig.1presents time necessary for handover with the two methods. Chunks ASCONF and HB can be sent at the same time, their position has been chosen here for reading purpose only. To consider handover effective, both hosts have to consider the new path as available: even if one node can emit on new path when receiving requests, we will take into account delivery time of acknowledgments. It has also to be noticed that in these graphs the CN is not multi homed: according to RFC it is not mandatory, only MN needs to be multi homed.[1][2] Equation [1] express handover time if heart beat is sent by mobile node along with ASCONF request, on contrary if CN is sending heart beat after receiving request a one-way delay is added [2]. Our solution can be expressed in two ways, by starting handover time at the beginning of configuration sequence ( ) or by starting it when network is detected ( ):

  Depending on which host sends the heart beat request and network characteristics, solution benefit can differ:  In the worst case, heart beat is sent by corresponding node [7] : o Both networks suffer the same delay (Td1=Td2=Td) and solution benefit equals to configuration time plus end-to-end delay : + Td, o If second network suffers a smaller delay (Td1>RTT2) then benefit is only configuration time .  Heart beat is sent by mobile node [6]: benefit is only configuration time .

Fig. 2 -

 2 Fig. 2 -Application delay while performing handover from satellite to Wi-Fi with our solution (a) and with DAC algorithm (b).

Fig. 3

 3 Fig.3(a) and (b) illustrates application behaviour while changing primary path several times. In this experiment, data was generated at 100 kilo-Bytes per seconds and there were no bandwidth limitation. Changes on global throughput when performing handover is limited by SCTP multi-homing : since congestion window is computed for each path, it can restart where it stops and no time is loss when going back on satellite network. In satellite networks, "slow-start" phase lasts several seconds and limits application throughput at start.

Fig. 3 -

 3 Fig. 3 -Impact on communication of multiple handovers: delay (a) and throughput (b).

Table 1 -

 1

			Delay	Quality of	Availability	Cost
				Service
	Wi-Fi	54 to	Low	802.11e	Range 100 to	Low
		100Mbps			200m
	3G/UMT	Contract	Average	Depending	Range 50m	Amount Data
	S	2Mbps	Propagation	Infrastructure	to 3km
	Satellite	Contract	Geo: 300ms	Depending	Depending	High
		1Mbps	Leo: 100ms	Contract	obstacles

Wi-Fi, 3G/UMTS and Satellite characteristics.

  Table 2 also illustrates timings from network connection to HB emission and from network connection to route configuration. It can be seen that the most important latencie is introduced by route configuration and link establishment. Interresting point is that configuring network interface in advance can lowered that delay by half.

		Network Connection to	Network Connection to	Network Connection to
		Data Emission	HB Emission	Route Configuration
	SOL	1,86s	0,890s	0,889s
	DAC	2,79s	1,84s	1,84s

Table 2 -Average latencies when performing handover with DAC algorithm and our solution.

 2


Ihsane Tou

Pascal Berthou

Thierry Gayraud

Fabrice Planchou

Valentin Kretzschmar

Emmanuel Dubois

Patrick Gelard

Which Transport Protocol for Hybrid Terrestrial and Satellite Systems?

Keywords: TCP, Hybrid networks, satellite, PEP

Satellite systems will complement terrestrial networks where the network could not be deployed for technical or economical reasons. Moreover, the natural broadcasting capacity of satellite networks makes it a good companion to terrestrial networks. Then, future services will be deployed over networks that combine terrestrial and satellite systems. The infrastructure heterogeneity could be problematic, for instance because of the delays variety. This article presents the problem from the point of view of the transport layer, the layer directly connected to the application, and compares several solutions to help future service developers using such network configuration.

Introduction

During the last decade a wide range of network access technologies have been developed to extend the access to the Internet services. In parallel the cellular networks, originally designed for voice/telephony mobile services have evolved to offer more services, and in particular Internet access. The convergence of fixed and mobile services has been achieved and standardized. Also, there has been significant progress on the level of the terminal handset (mobile phone, Smartphone and laptop) whose size has been significantly reduced, while providing more capabilities and wireless interface support.

With NGN and 4G architectures, services or applications are designed independently of the underlying access network (wireless, cellular, wired, optical, etc) based on the IP core technology, which is the convergent corner-stone of telephony and data services. The always-on paradigm is conceived as a generalized mobility for user services, allowing seamless service switching across any compliant network access technology.

This means that applications (thus the underlying transport protocols) have to be persistent to the network switching. This is a challenging objective since the access media are heterogeneous and potentially operated by various actors. This paper exposes the problems met by the transport layer and especially TCP with such heterogeneity and compares several solutions to help future service developers using hybrid networks. The performances of the TCP protocol are compared according to different TCP versions, in the specific case of hybrid handover.

However, just before, the next section presents several scenarios envisaged for the integration of satellite access systems in the future LTE networks, what we call hybrid satellite and terrestrial networks.

Hybrid terrestrial and satellite systems

The satellite integration with terrestrial network can be achieved in several manners. Three complementary visions are presented. A tightly coupled architecture, an integrated approach in which a given mobile system (3G, LTE, WIMAX) is extended to support the satellite media, as an alternate radio access channel for the mobile user, in a completely transparent way. A "relay integration", in which the satellite is integrated within the mobile network infrastructure, not directly at the mobile air interface, but beyond a specific satellite relay enabling the access to the core mobile infrastructure. And a "loosely coupled integration", in which a satellite specific interface is added on the mobile terminal enabling the connection to IP data network, through access network. This involves multitechnology (multimodal) mobile terminals, handling several interfaces and running the convenient protocol (specific media access: DVB-RCS+M for instance).

The first two architectures hide the network heterogeneity with a dedicated layer 2 transparent for the upper layers. In the tightly coupled vision, the terminal can be aware of the satellite access; in the relay architecture the heterogeneity is embedded in the network. The loosely coupled architecture needs a third protocol to assure the network change, mobile IP would be the solution, however the network characteristics will be hidden too. Also the heterogeneity is a problem for the transport layer, it appears that an agnostic transport protocol (i.e. it does no know the underlying networks) should be a better solution as the knowledge of the underlying network is a risky hypothesis.

Impact on the transport layer

The hybridization of the networks may cause several troubles with the transport protocols. The firsts occurs when changing network (i.e. leaving a terrestrial network for a satellite network), the others when the transport protocol uses old parameters (Congestion WiNDow size, timers) on a new network (i.e. a TCP connection with its parameters set according to a terrestrial network uses a satellite network with a limited bandwidth and a long delay).

The handover model: According to the network specifications and the reception conditions, the handover between two networks can generate service interruption or not. It can vary from several packet losses (soft handover), to short interruption (several seconds), to a long break with network addressing change (mobile IP should resolve this problem). The behavior of the transport layer will depend on this. In this paper we consider seamless handover and short interruptions that could be implemented using tighten or relay architecture. We exclude mobile IP scenarios as we previously show that such handover in a satellite system is too long for the transport layer (TCP connection reset) [START_REF] Arnal | IP mobility and it's impacts on satellite networking[END_REF].

We call the firsts scenarios "make before break" and the last one "break before make" as the adaptation is made after the handover. In the first cases the new layer 2 is set-up before the old one is deactivated. Two links are available during a short period of time when the hand-over arises. This can provoke a disordered reception of packets and then trigger TCP congestion control algorithms. On the opposite, in the last case, the new link is established only when the old is down. The effects are a risk of disconnection if the disruption is too long (application or TCP timeout), the losses could be interpreted as a congestion an trigger the TCP congestion control algorithms, or an expiration of the TCP retransmission timeout (RTO) that will starve the connection throughput.

Impact of the parameters variation:

Its obvious that delay, bandwidth and in smaller proportion the loss rate will vary according to the connected network. The transport layer "guess" these parameters through timers for the delay, congestion windows for the bandwidth. Loss rate is slightly different, as it will impact the reaction of the protocol. When changing network, the transport protocol could be duped by the old parameters and do not adapt properly to the new network. Considering TCP, the useless retransmissions could increase because of a to small value of the RTO, or spurious RTO may occur as side effect. It could increase the unused bandwidth (i.e. waste of resources): TCP may not be able to use the increased bandwidth of new network or in the opposite provoke a real congestion if the congestion window is too big for the network capacity.

Many TCP versions have been proposed to the IETF to adapt to a particular network. Some are general (as TCP options), while others are designed to change a particular TCP behavior, or tends to adapt TCP functioning in the conditions of a given media technology (as, "Wireless context"), and some are completely specific to the vertical handover purpose. In this paper we focuses on the hybridization problematic, but in the following part we briefly summarize the classical TCP versions to compare it when testes in a hybrid context.

Transport protocol alternatives

TCP is a byte-stream connection oriented protocol. The connection management is handled by the sole endpoints. TCP uses a sliding-window based congestion control scheme: the size of the transmit window is the lesser of the receiver's advertised window size awnd and the sender's congestion window size cwnd.

The size of cwnd is determined by well-known algorithms designed to limit the effects of congestion in the Internet, including slow start, congestion avoidance, fast retransmit, and fast recovery.

The main element that differentiates the TCP implementations is the management of the size of its emission window. Many different approaches have been proposed, and published at IETF, without reaching the standard status. Therefore each operating system may use its own, as preferred release. This section presents a brief overview of different versions that can be interesting because they are well spread and therefore efficient or because they are adapted to a specific domain of application like satellites, mobility or high-bandwidth media.

Reno/New Reno: TCP Reno uses a loss-based congestion control window. It uses the TCP's mechanism of increasing the cwnd by one segment per RTT for each received ACK and halving the cwnd for each loss event per RTT. It uses all well-known congestion control. The TCP New Reno improves retransmission during the fast recovery phase of TCP Reno. Compound: Compound TCP (CTCP) is designed to fit quickly to the bandwidth available while staying TCP friendly. Its particularity is to be both delay-based and loss-based. It manages two cwnds; the classic one like in TCP Reno and the delay based one dwnd which is used only during congestion avoidance phase. CTCP is currently implemented over Windows Vista, Seven and Server 2008. Cubic: The Window is a cubic function of time since the last congestion event, with the inflection point set to the window prior to the event Cubic does not rely on the receipt of ACKs to increase the window size. Cubic's window size is dependent only on the last congestion event. Cubic TCP is implemented and used by default in Linux kernels 2.6.19 and above. Hybla: TCP Hybla is a TCP enhancement conceived with the primary aim of counteracting the performance deterioration caused by the long RTTs typical of satellite connections. It adopts the Hoe's channel bandwidth estimate, timestamps and packet spacing techniques.

Fortunately a number of TCP extensions have been proposed at IETF to improve TCP behavior. Some are general (as TCP options), while others are designed to change a particular TCP behavior or tends to adapt TCP functioning in the conditions of a given media technology (e.g. TCP Sack, Quick-Start), and some are completely specific to the vertical handover purpose (Freeze TCP [START_REF] Goff | Freeze-TCP: A true endto-end TCP enhancement mechanism for mobile environements[END_REF], Fast Adaptation Mechanism [START_REF] Li | A fast adaptation mechanism for TCP veritcal handover[END_REF]).

In the following section, we compare the TCP performances of different real TCP stacks during a handover in a hybrid network.

Experimental test bed description

The testbed relies on a satellite emulator (SATEM) developed by ASTRIUM that emulates the handover between satellite and wired network by selecting the available bandwidth, the propagation delay and the Packet Loss Ratio (PLR); This emulator is based on the layer 3 linux network emulator (netem). Client and Server (iperf), a network sniffer (Wireshark) and a TCP proxy (PEPsal) allow to generate, capture and produce the results. The Figure 1 shows a detailed layout of our testbed.

Figure 1 Testbed description

A Performance Enhancing Proxy as been added to be compared to end-to-end solutions. PEPsal [START_REF] Caini | Analysis of TCP live experiments on a real GEO satellite testbed[END_REF] is an integrated PEP scheme based on the TCP-splitting technique that adopts TCP Hybla.

The following metrics has been chosen to evaluate the TCP performances: The sequence number evolution of the transmitted packets is useful to monitor the connection efficiency and regularity. It also tells information about packet loss, connection cuts and the amount of data transferred. The comparison of the sequence number evolution is interesting because it can be observed independently of the TCP version used. The Congestion Window size (cwnd), the application end-to-end delay and throughput where also used but not presented in this paper. Theses metrics have been captured and processed using the WEB100 Project and TCPTRACE [START_REF] Ostermann | TCPTRACE[END_REF].

We assume the satellite and the wired network parameters on emulated SATEM as:

 Emulated satellite link: Bandwidth 512 Kbps, RTT 500 ms, P.LR. 10-e5  Emulated wired link: bandwidth 2 Mbps, RTT 50 ms and free P.L.R. We choose to present first results according the variation of only one parameter at one time, to focus on the problems it raise.

TCP versions over satellite comparison

We first choose to compare the TCP versions over the satellite part, even if it has been extensively studied, has the performances of Windows Seven Compound version are surprising.

The sequence number evolution graph (a) shows similar performances between hybla, cubic and compound, however compound if more aggressive and benefits rapidly of the available bandwidth without undergoing losses as hybla or cubic. The throughput evolution (b) confirms a better behavior of compound and shows that after 1 minute, the tail of the hybla and cubic curve is the result of large buffers flushing and retransmission management that is not a positive aspect for the application.

TCP versions affording soft handover

Our experiences focus on changing one parameter during a handover as described above to see the influence of each parameter during the mobility processes.

Delay variation

The figure 3 (a) shows the evolution of sequence numbers with two handovers. The bandwidth has been set to 2 Mbps during the entire test (60s) and the propagation delay is changing (RTT ~ 500 ms in satellite to 50 ms the wired network). 3 phases have been defined, between 0-20 seconds, TCP streams through the satellite network, between 20-40 seconds, they cross the wired network and finally between 40-60 seconds they go back to the satellite network.

Figure 3 -TCP sequence number evolution with delay (a) and bandwidth (b) variation

In Figure 3 (a), as shown previously, hybla, cubic, compound perform better on the satellite part than reference TCP versions (westwood, reno). During the WiFi phase, no significant difference can be observed. The main difference resides when coming back to the satellite network. Cubic affords a bad congestion windows setting and generates losses, hybla too but in smaller proportions. Compound restarts faster and rapidly catches up its delay. The compound dual windows management proves to be effective after a handover.

Bandwidth variation

The Figure 3(b) shows the evolution of sequence numbers with two handovers. We set the RTT to 50 ms in the entire test (60s) and vary the available bandwidth (512 Kbps in satellite to 2 Mbps the wired network). The flows undergo 3 phases first they through the wired network, then they cross the satellite network and finally they go back to the wired network.

All streams have a quite similar behavior; expect Cubic which suffers at the end of the phase 2. The buffers are over and the cut at the second 43 is a consequence of the aggressiveness of the Cubic mechanism with low bandwidth. Cubic tries to growth up a maximum bandwidth.

PLR variation

The variation of the Packet Loss Ratio did not bring significant results, as the reaction of TCP versions should be comparable when affording a loss (considered as a congestion). Cubic obtained the worsts results because of its aggressiveness.

PEP or not

One of the main question when dealing with specific medium (i.e. satellite) is does we need a PEP or not. Considering our previous result with the new TCP versions over satellite systems, we try to show in this part that PEP are no more mandatory in such configuration.

PEP with satellite system

The figure 4 presents the evolution of sequence number of 6 TCP versions through the satellite network. It is clear that the PEPsal solutions are better than end-to-end TCP (in brown is Reno). We notice the exemplary behavior of CTCP (without PEP), which remains stable, little bit under but holds the comparison with the PEP solutions.

PEP with mobility

The Figure 4 shows the evolution of sequence numbers with two handovers. In the graph (a), we fix the bandwidth to 2 Mbps during the entire test (60s) and vary the propagation delay (RTT ~ 500 ms and 50 ms). In the second graph (b), we fix the RTT to 50 ms during the entire test (60s) and vary the available bandwidth (512 Kbps in satellite to 2 Mbps in the wired network). The 3 handovers are defined as previously, from satellite to wired network to satellite. The graph (a) clearly shows the superiority of CTCP in Phase 1 and 3. PEPsal has a good result in both phases but with a CTCP advantage. During the transition to the wired network, all flows catch up from the bad performance (especially Cubic), because of the short propagation delay.

In the graph (b), the performance is quite identical between the solutions. A small advantage was noticed during the transition to terrestrial network for the PEPsal.

The impact of "break before make" handover

This paragraph compares the behavior of TCP versions when the handover is not error free (break before make scenario). The break was set to 500ms and 1000 ms.

Break (500/1000 ms) before make, fixed bandwidth (2Mbps) and delay variation (500-50-500 ms RTT)

The Figure 5 (a) shows the TCP connection behavior when the break takes 500ms. When the streams through the satellite link in the first phase, CTCP confirms the results we had before. The same applies to PEPsal and Hybla, which are just behind. After the first break, at second 20, the restart of all streams is at least about 5 seconds for Cubic, and Hybla PEPsal. CTCP reacts faster and recovers the transmission in about 2 seconds. We get the same conclusion at the second 40 when the second handover occurs.

In the graph (b), when the break takes 1 second, we observed the same behavior after the handover, but with more difficulties for Cubic. Break (500/1000 ms) before make, fixed delay (50 ms) and bandwidth variation (512K-2M-512K bps)

In the Figure 6 (a), we see at the beginning of the transmission that Cubic is better than other versions, as the delay is low (but with a small bandwidth). During the two handovers, Cubic has a high cut, and restart is difficult. Hybla and PEPsal have naturally the same reaction during handovers. CTCP better manages the break, and recovers better the connection, which takes about 2 seconds.

When the break stays 1 second, all flows except CTCP, were completely broken after handover (b). This paper proposes the evaluation of different TCP versions, using real stacks, in the specific problematic of the handover between terrestrial and satellite networks. The good behavior of the transport layer is crucial to offer quality services over hybrid networks. The surprising conclusion of this study is that windows seven compound gives very good results, in some cases better than those with PEP's, especially over large propagation delays. Tests with the "break before make" showed the difficulties of some TCP restart compared to others, and attest CTCP as the best version for handovers with or without breaks.

Figure 2 -

 2 Figure 2 -TCP versions comparison (a) Sequence number (b) Throughput

Figure 4 -

 4 Figure 4 -Sequence number evolution with PEP influence over a satellite

Figure 4 -

 4 Figure 4 -Comparison between PEP TCP and e2e TCP during a handover (delay (a) and bandwidth (b) variation)

Figure 5 -

 5 Figure 5 -Sequence number evolution with (a) 500 ms (b) 1000 ms break

Figure 6 -

 6 Figure 6 -Sequence number evolution with (a) 500 ms (b) 1000 ms break