A Martínez

W Ramírez
email: wramirez@ac.upc.edu

M Germán
email: mgerman@ac.upc.edu

R Serral
email: rserral@ac.upc.edu

E Marín

M Yannuzzi
email: yannuzzi@ac.upc.edu

X Masip-Bruin

An Approach to a Fault Tolerance LISP Architecture 1

Keywords: Internet Routing Scalability, LISP, Fault Tolerance 1

Next Generation Internet points out the challenge of addressing -things‖ on both a network with (wired) and without (wireless) infrastructure. In this scenario, new efficient and scalable addressing and routing schemes must be sought, since currently proposed solutions can hardly manage current scalability issues on the current global Internet routing table due to for example multihoming practices. One of the most relevant proposals for an addressing scheme is the Locator Identifier Separation Protocol (LISP) that focuses its key advantage on the fact that it does not follow a disruptive approach. Nevertheless, LISP has some drawbacks especially in terms of reachability in the border routers. In face of this, in this paper we propose a protocol so-called LISP Redundancy Protocol (LRP), which provides an interesting approach for managing the reachability and reliability issues common on a LISP architecture, such as those motivated by an inter-domain link failure.

Introduction

In the past years, early forms of ubiquitous communication have arisen and become more evident, as society expectations towards technology increases. These facts seem to prove that current Internet will naturally evolve to an Internet of Things (IoT) as a new dynamic communication scheme where objects, services, spaces and even people may be given a unique number, almost avoiding barriers for re-cognizing, locating, addressing, reaching, controlling and enjoying almost anything via the Internet, through a mix of heterogeneous wired and wireless network infrastructures.

The current Internet semantic overloading of addresses, where addresses are simultaneously referred to identifiers and locators of a node, is an important constraint over mobility and scalability concerns. In a world where a huge volume of objects can be uniquely identified and also where objects capacity of mobility increases over time, decoupling of naming and location seems to be one of the first steps towards the evolution to a IoT. Several factors, such as the rise of multihoming sites, semantic overloading of IP addresses, among others, affect the scalability of the global Internet routing table, fueling its size and dynamics. Several proposals have emerged to solve these issues: SHIM6 [START_REF] Nordmark | Shim6: Level 3 multihoming shim protocol for ipv6, RFC 5533[END_REF], Six/One Router [START_REF] Vogt | Six/One Router: A Scalable and Backwards Compatible Solution for Provider-Independent Addressing[END_REF], HIP [START_REF] Yang | Host Identity Protocolrealizing the Separation of the Location and Host Identity[END_REF], Multipath TCP [START_REF] Handley | Multipath Transport, Resource Pooling, and implications for Routing[END_REF], GSE [START_REF] Massey | A Proposal for Scalable Inter-net Routing & Addressing‖[END_REF] and LISP [START_REF] Farinacci | Locator/ID Separation Pro-tocol (LISP),‖ Internet Draft[END_REF] are just a few to name. The latter seems to be one of the strongest as already considered by the Internet Engineering Task Force (IETF).

The LISP concept is based on the idea of decoupling host identifier (Endpoint identifier, EID) and host localization (Routing locator, RLOC). The main benefit from using LISP is that while locators are AS-level distributed (allocated to the external interfaces of the border routers) the identifiers are only locally distributed, therefore reducing the overall routing load throughout the network. While from a deployment perspective LISP is a nondisruptive approach, the existing control plane proposals have some drawbacks especially in terms of reachability in the border routers. Since these border routers are responsible for carrying out the mapping between EIDs and RLOCs, these issues may hinder its possible deployment. In this paper, we conceptually propose the basics of a new protocol, so-called LISP Redundancy Protocol (LRP) which is designed for managing the reachability and reliability issues, such as those motivated by either an inter-domain link failure, a border router failure, an intra-domain link/node failure or an intra-domain TE action.

The rest of this paper is organized as follows. First, section 2 presents the current Internet architecture and its scalability problems; section 3 introduces LISP basics; section 4 presents the LRP as a potential solution for the control plane problems; section 5 discusses future work related issues. Finally, section 6 presents conclusions.

Background and Problem statement

The Internet architecture is organized into Autonomous Systems (ASes). The ASs interconnections generate a hierarchy between different Internet Service Providers (ISPs).

In this hierarchical network structure, the Internet routing system is largely based in the Border Gateway Protocol (BGP) [START_REF] Rekhter | A Border Gateway Protocol 4 (BGP-4). RFC 4271[END_REF], a long lived path-vector protocol which is used to exchange reachability information between ASes. Being a policy-routing protocol, it provides operators with the freedom to express their enterprise requirements and policies, allowing the attachment of several attributes for each route or network prefix. However, it has been largely demonstrated in the literature that the currently deployed Internet architectural model suffers from some weaknesses, mainly on the terms of routing scalability issues that along with the specific problems on the Internet addressing scheme require the deployment of new solutions. Next subsections detail most relevant aspects limiting routing performance on the overall Internet. It is worth highlighting that any solution proposed for end-to-end addressing must consider a completely heterogeneous network scenario consisting of different wired and wireless network segments distributed along the route, where some user (e.g., quality) and network (e.g., physical attributes) requirements must be met.

Internet Routing Scalability problems

Recent studies including the Internet Architecture Board (IAB) report [START_REF] Meyer | Report from the IAB Workshop on Routing and Addressing[END_REF], reveal that Internet routing is facing serious scalability problems, all involving both the size and dynamics of the global routing table in the Internet's Default Free Zone (DFZ).

The global routing table size in the DFZ has been growing at an alarming rate in recent years [START_REF] Houston | The growth of the BGP table -1994 to present[END_REF], till reaching now a total of 36.717 ASes that originate 355.262 IPv4 prefixes (see Figure 2) despite several limitations such as lack of IPv4 addresses, strict address allocation and routing announcement policies. Although IPv6 deployment would remove the problem of lack of IPv4 addresses, there is a strong concern that the deployment of IPv6 on a large scale could result in a significant growth of the routing table .   The IAB report [START_REF] Meyer | Report from the IAB Workshop on Routing and Addressing[END_REF] identified the following factors as the main reasons behind the rapid growth of the global routing table in the DFZ:

 Multihoming.  Traffic engineering.  Non-

aggregable address allocations

In [START_REF] Bu | On characterizing BGP routing table growth[END_REF] authors conclude that address fragmentation, caused by multi-homing and load balancing is the major reason of BGP table growth.

Dynamics of the BGP Control Plane Information

In [START_REF] Oliveira | Measure-ment of highly active prefixes in BGP[END_REF], a systematic study of highly active prefixes is presented, concluding that a small fraction of advertised prefixes are responsible for a relevant amount of churn in BGP; furthermore, they found that some generators of BGP beacons, used for active monitoring of BGP updates, appear as highly active. Despite the big amount of related work, the dynamics of the BGP control plane information (i.e., the exchanging of updates messages due to the advertisement of new prefixes) remains unknown, but certain evidence exists of Long Range Dependence [START_REF] Flavel | ‖Modeling BGP Table Fluctuations[END_REF]. As BGP propagates changes to the best path, a single router may send multiple updates based on one triggering event, and further, cause induced updates at other locations; examples of such events are link failures, newly added networks, prefix deaggregation and policy changes, among others. Moreover, it is important to notice that, since the routing information is subject to successive filtering by internal ASes policies, any route view of the network is always partial, determined by the local point of observation. On the other hand, a relatively small number of ASes are responsible for a disproportionately large fraction of the update churn that is observed today. In turn, another problem motivated by the growing of the BGP updates is the BGP convergence time, since as the larger the topology complexity is the longest the convergence time, hence motivating the network to take longer to recover from failures.

Multihoming Sites

Another factor related to the growth of the routing table refers to the multihoming sites. For a network edge to be reachable by any service provider, the network-edge address-prefixes should be visible in the global routing tables. Meaning that no service provider can aggregate these address prefixes within their own address prefix, even if the network edges have addresses that belong to the provider-assigned address block. In addition, the network edges are increasingly obtaining provider-independent addresses from the Regional Internet Registries (RIRs), in order to avoid the renumbering every time a change of service provider happens. In summary, the topological information based on prefix-aggregation per provider is badly altered by multihoming, and in turn, leads to rapid growth of the global routing table.

Semantic Overloading

Another critical problem is the semantic overloading of IP addresses. This is because an IP address identifies a host (in fact its interface), and also serves to locate the host on the network. In this addressing scheme when a host changes of network provider, its IP address changes, therefore changing not only the network providing host access but also the host identifier. For upper layer applications that have IP addresses hard-coded for a host, this represents a severe mobility constraint. In short, the semantic overloading of IP addresses is the main problem when talking about renumbering a network. The basic idea is that an EID represents an end-host IP address, while RLOCs represent the IP addresses where end hosts are located. At border routers EIDs are mapped into RLOCs, following a map-and-encap scheme, a basic mechanism of a LISP architecture. The scaling benefits arise when EID addresses are not routable through the Internet -only RLOC addresses are globally routable, allowing efficient aggregation of the RLOC address space.

3.

LISP overview

Recent studies show that LISP offers some key advantages. For instance, authors in [START_REF] Quoitin | Evaluating the Benefits of the Locator/Identifier Separa-tion[END_REF] show that the size of the global routing table can be reduced by roughly two orders of magnitude with LISP. Next subsection details how LIST performs on both the data and control planes.

Data Plane

Data plane performance is described on the example shown in Figure 3 2 . When the local end host S with EID address 190.1.1.1 wants to communicate with end host D with EID address 200.1.1.2 in a different domain, the following sequence of events occur in LISP:

1) The first step is the usual lookup of the destination address ED in the DNS.

2) Once ED is obtained, the packets sourced from ESource traverse the domain and reach one of the local border routers. In LISP the latter are referred to as Ingress Tunnel Routers (ITRs). 3) Since only RLOC addresses are globally routable, when an ITR receives packets toward ED, it queries the control plane to retrieve the EDestination-to-RLOC mapping. 4) After the ED-to-RLOC mapping resolution, the ITR encapsulates and tunnels packets between the local RLOC address (ITR address 3.3.3.2 in the example) and the RLOC address retrieved from the mapping system, the Egress Tunnel Router (ETR) address in LISP terminology (either 4.4.4.2 or 10.0.0.2 to ED depending on the mapping). 5) At the destination domain, the ETR decapsulates the packets received through the tunnel and forwards them to ED -which, as mentioned above, is locally routable within the domain. From the first packet received, the ETR caches a new entry, solving in this way the reverse mapping for the packets to be tunneled back from EDestination to ESource.

Fig. 2 The basics of LISP

Control Plane

Despite the benefits of using LISP described in section above, the proposals for the LISP control plane present some major challenges. These challenges lie in the fact that since EIDs are not globally routable through the Internet, a mapping system is necessary between EIDs and RLOCs. LISP does not specify a mandatory mapping system, and as a consequence, different proposals can be found in the recent literature, such as ALT [START_REF] Farinacci | Lisp alternative topology (lisp+alt)‖. Internet Draft[END_REF], NERD [START_REF] Lear | Nerd: A not-so-novel eid to rloc database‖[END_REF] or Map Server [START_REF] Fuller | LISP Map Server‖[END_REF]. Besides, in [START_REF] Yannuzzi | Managing interdomain traffic in Latin America: a new perspective based on LISP [Topics in Network and Service Management[END_REF] we introduced a new control plane for LISP; the new control plane presents an improvement on three aspects respect to the existing solutions; (i) firstly, -First packets drop problem‖ when an ITR does not have a mapping for an EID-prefix; (ii) secondly, potential increase in the latency to start a communication due to the mapping resolution; and (iii) in order to avoid a two-way mapping resolution, the ITR is used as the local ETR for the packets sent from D to S. The latter introduces limitations in terms of inbound Traffic Engineering, especially, when outbound and inbound traffic policies do not match. Despite these improvements there are other issues relating to reachability and reliability that have not been resolved, such as those motivated by an inter-domain link failure.

4.

Making the way to a fault tolerance LISP.

In [START_REF] Yannuzzi | Managing interdomain traffic in Latin America: a new perspective based on LISP [Topics in Network and Service Management[END_REF] authors propose a new LISP control plane, aimed to overcome the issues derived by current mapping systems such as ALT, CONS or NERD. The main issue behind these approaches is related to the first packet drop problem, which refers to the mapping resolution for a prefixed EID for the first outgoing packet, this also derives in the potential increase in the latency to start a communication. This newly proposed control plane is based on the idea of retrieving EID-to-RLOC mappings within the DNS Resolution time. A major shortcoming of the solution proposed in [START_REF] Yannuzzi | Managing interdomain traffic in Latin America: a new perspective based on LISP [Topics in Network and Service Management[END_REF] is that the mappings between EIDs and RLOCs are replicated in all of the edge routers within the same AS. Despite the fact that this option ensures improved reachability, unfortunately it may bring scalability problems since each router must store mapping information that rarely needs to use (i.e. the mapping table size), thus increasing the latency time to find a mapping. This new issue directly affects the memory component within the router, which is currently a bottleneck in the computer system compared with processing capacity. In order to minimize the mapping information managed by a router, hence minimizing the latency time, and in turn, ensuring the highest possible reachability, the LISP Redundancy Protocol (LRP) is proposed, which is inspired by the Cisco's Hot Standby Routing Protocol (HSRP) [19]. This architectural approach essentially permits to configure two routers for mapping purposes, so that before a failure on one of them, the other can supplant it (Master-Slave model). The contribution of the LRP is that it extends HSRP functionalities by creating different logical groups. In this scenario, border routers can be members of different groups, and the "key" difference between LRP and HSRP focuses on the fact that LRP enables a router to be Slave in a group and Master in another (see Figure 4). By implementing this feature all routers can be in forwarding mode, hence overcoming the limitation present in [START_REF] Yannuzzi | Managing interdomain traffic in Latin America: a new perspective based on LISP [Topics in Network and Service Management[END_REF], namely to avoid the need of replicating the entire mapping on all the border routers. In case of either a link or border router failure, the last one will interchange his mapping with the border router that is now responsible of handling the traffic in this logical group.  The xTRs can be clustered into different LRP groups or pairs.  The Mappings are pushed onto the LRP groups or pairs.  All the xTRs in the group can carry traffic (active rather than standby).  No need for data-probes when the xTR does not have a mapping.

In the following subsections we consider different scenarios that may originate reachability and/or reliability problems and require solutions to be managed by the current proposed protocol

Inter-domain link failure in an ITR

In the following we will discuss and describe the actions that are executed in order to solve the failure of an inter-domain link. In step 1 of Figure 5, the traffic is sent to the edge router (ITR1), which is responsible for encapsulating the traffic and send it through its international links to the destination. When the international link fails (step 2) the ITR1 automatically detects this event and in real time forwards all the incoming traffic to the other ITR belonging to its LRP group (step 3). ITR2 has the correspondent mapping since it shares the LRP Group with ITR1 and now is in charge of encapsulating and sending this traffic to its destination (step 4). On the other hand, by means of the internal routing protocol (running in the AS), the failure of the international link is notified to update the routing tables and hence the traffic is rerouted (step 5). In time, the LISP Control Box (LCB) would be responsible for reconfiguring the mapping of the different ITRs with the purpose of load balancing the outbound traffic (step 6). Finally, the traffic is rerouted according to internal routing policy (step 7). In conclusion, in this scenario our border architecture prevents packet loss and in particular the sending of data-probes.

ITR failure or unexpected shutdown

If one ITR fails or is shutdown, gigabits of data would be lost. To overcome this situation the LISP control plane must converge to the IGP running in the AS to send back first gigabits of data-probes and then after successful mapping, send data according to the normal procedure. The following describes the step followed by the LRP to prevent any loss of data and to avoid sending data-probes. In step 1 in Figure 6, the traffic is sent to edge router (ITR1), which is responsible for encapsulating the traffic and send it through its international link to destination. When ITR1 fails (step 2) the HSRP that runs between ITR2 and ITR1 converges, and automatically ITR2 assumes the role of Master of the LRP group and forwards all traffic that arrives (step 3) in real time. The convergence of HSRP (HSRP detected in about 3 seconds the router failure) is much faster than any IGP, such as Open Shortest Past First -OSPF. In turn, the internal routing protocol that is running notifies the failure of ITR1 (step 4) to update the routing tables and hence allowing the traffic to be rerouted. On the other hand, the LCB would be responsible for reconfiguring the mapping of the different ITR to balance the outbound traffic load (step 5). Finally, the traffic is rerouted according to the IGP (step 6). In conclusion, in this scenario our border architecture minimizes the packet loss and in particular the sending of data-probes.

ITR Mapping Miss

In this scenario, an action of Traffic Engineering or an internal failure (step 1 in Figure 7) makes the traffic to be rerouted. When the packet reaches a border router (step 2) that has no corresponding mapping, this router makes a broadcast to other LRP Groups of the packets that are arriving (step 3), and in turn, the LRP Group sends a Map-Request to the LCB (step 4) that is responsible for handling all mappings within an AS. A LCB (LISP Control Box) is an entity introduced in [START_REF] Yannuzzi | Managing interdomain traffic in Latin America: a new perspective based on LISP [Topics in Network and Service Management[END_REF] responsible of all mappings within an AS which might be a standalone device or run as an instance of a PCE. The LRP Group that owns the required mapping, sends it via unicast to the LRP Group responsible for these packages (requester) (step 5), and encapsulates and forwards the traffic. While traffic is derived from the LRP Group mapping holder (step 6), the LCB sends to the LRP Group who sent the Map-Request the mapping necessary to encapsulate the packages (step 7). Finally, the LRP Group can now encapsulate packets and, therefore, makes the package forwarding through the LISP data plane (step 8). In conclusion, in this scenario our border architecture prevents packet loss and in particular the sending of data-probes.

Future Work.

In our network scenario we assume that LRP nodes are all part of a broadcast domain. In today's ISP core networks this is not always the case, with the introduction of new technologies like MPLS, where edge routers reach each other using LSP (Label switched Path) across an MPLS core. In this network scenario a single broadcast domain does not exist anymore.

Another similar problem can occur when BGP confederations are introduced. To overcome these challenges, extensions to LRP have to been made and configurations in edge routers have to be carefully taken into account.

We expect to present simulations of our proposal with measures of improvement of a response to a EID-RLOC mapping in a future article.

Conclusions

In this paper we present the concepts of a new protocol aimed to overcome the scalibility issues that surround the new control plane approach presented in [START_REF] Yannuzzi | Managing interdomain traffic in Latin America: a new perspective based on LISP [Topics in Network and Service Management[END_REF], in order to improve reachability and reliability for an Autonomous System. LISP Redundancy Protocol is built based on the HSRP protocol with the addition of new features. In turn, this new proposed architecture deals with two problems. Firstly, the sending of data-probes which involves sending a lot of information without knowing where is to be sent. Secondly, it avoids packet losses in the presence of a failure in the network, what is achieved in all scenarios except when the failure occurs at the edge router of the network (in this case, LRP only minimizes packet loss). Currently, we are working on an implementation of the LRP Protocol, in order, to obtain measurements on the convergence time in the network, considered as a primary metric for determining the scalability and efficiency of routing schemes.

Fig. 1

 1 Fig. 1 Growth of the BGP Tables at DFZ Routers

Fig. 3

 3 Fig. 3 Master/Slave Model HSRP vs. LRP

Fig. 4

 4 Fig. 4 LRP: Inter-domain link failure

Fig. 6

 6 Fig. 6 ITR has no mapping from EID-to-RLOC

  LISP uses IP-over-IP tunnels deployed between border routers located at different domains. The IP addresses allocated to the external interfaces of the border routers act as Routing Locator (RLOC) addresses for the end systems in the local domain. Since an AS usually groups several border routers, the local Endpoint Identifier (EID) addresses can be reached through multiple RLOC addresses. Hence, LISP separates the overall address space into two parts, where only addresses from the RLOC address space are assigned to the transit Internet. Therefore, only RLOC addresses are routable through the Internet, that is, EID addresses are considered routable only within their local domain. In addition, a number of scaling benefits would be realized by separating the current IP address into two different spaces; among them are:  Reduction of the routing table size in the Default Free Zone (DFZ)  More cost-effective multihoming for sites that connect to different service providers  Easy renumbering when clients change providers  Traffic engineering capabilities  Mobility without address changing

This work was partially funded by the Spanish Ministry of Science and Innovation under contract TEC2009-07041, and the CIRIT (Catalan Research Council) under contract

2009-SGR1508.

This example is extracted from -The Locator Identifier Separation Protocol (LISP)‖, by David Meyer, published in Internet Protocol Journal, vol 11, nº:1


Enda Fallon
email: efallon@ait.ie

Liam Murphy
email: liam.murphy@ucd.ie

John Murphy
email: j.murphy@ucd.ie

Chi Ma

TRAWL -A Traffic Route Adapted Weighted Learning Algorithm

Keywords: MIH, vehicular systems, handover, neural networks

Media Independent Handover (MIH) is an emerging standard which supports the communication of network-critical events to upper layer mobility protocols. One of the key features of MIH is the event service, which supports predictive network degradation events that are triggered based on link layer metrics. For set route vehicles, the constrained nature of movement enables a degree of network performance prediction. We propose to capture this performance predictability through a Traffic Route Adapted Weighted Learning (TRAWL) algorithm. TRAWL is a feed forward neural network whose output layer is configurable for both homogeneous and heterogeneous networks. TRAWL uses an unsupervised back propagation learning mechanism, which captures predictable network behavior while also considering dynamic performance characteristics. We evaluate the performance of TRAWL using a commercial metropolitan heterogeneous network. We show that TRAWL has significant performance improvements over existing MIH link triggering mechanisms.

Introduction

The IEEE 802.21 working group propose the MIH standard [START_REF]IEEE Standard for Local and metropolitan area networks -Part 21: Media Independent Handover Services[END_REF] to support the communication of network critical events to upper layer mobility protocols. While the MIH standard defines the interface for communication of link layer metrics to upper layer mobility protocols it does not provide specifics on the mechanisms which should be employed to trigger such events. Many existing algorithms [START_REF]The Network Simulator NS-2 NIST Add-on -Neighbor Discovery[END_REF][3] [START_REF] Woon | Effective Link Triggers to Improve Handover Performance[END_REF] define static thresholds for performance metrics such as RSS. When these thresholds are exceeded events such as Link_Going_Down (LGD) and Link_Down (LD) are triggered. For set route vehicle systems such approaches are limited as they do not consider how the predictable nature of movement enables historic performance metrics to influence predictive link triggering.

In this paper we focus on the optimisation of network handover for set route vehicles such as public transport busses and trains. Such vehicles typically operate in preconfigured routes which are repeated at routine intervals sometimes many times a day. We propose TRAWL, an unsupervised feed forward neural network, which captures repetitive network behaviour while also considering the dynamic performance characteristics of heterogeneous networks. TRAWL consists of 2 major components; Route Identification and Management (RIM) and an Unsupervised Vehicle Learning Algorithm (UVLA). RIM is responsible for the configuration and removal of routes in the system. RIM also maintains the relationship between Access Points (APs) and vehicle routes. UVLA consists of a feed forward neural network which implements the decision logic for TRAWL. UVLA input consists of a selection of normalised performance metrics. The number of neurons in the output layer is dependent on the network configuration; 1 for homogeneous networks, 2 or more for heterogeneous networks. When the stimulation of a neuron exceeds a user defined activation threshold, the neuron "fires" producing a binary positive output. Positive binary output triggers path switchover to the path specified by the inputs. UVLA aims to maximise throughput per route cycle. In order to determine the learning rate we calculate the rate of change of a linear regression line through historic cycle throughput. A large rate of change results in a large alteration of weights. A small rate of change results in a small alteration of weights.

We evaluate our approach against the standard MIH approach used in [START_REF]The Network Simulator NS-2 NIST Add-on -Neighbor Discovery[END_REF] using performance metrics from a commercial heterogeneous network installation. The standard MIH approach is limited as uses a static RSS threshold of typically -80dBm to -85dBm to determine when connection termination should occur. For a commercial heterogeneous network implementation where APs are positioned for hot spot coverage, RSS ranging for -80dBm to -90dBm is common. By exploiting historic performance trends TRAWL determines that significant throughput can still be achieved at this RSS level, particularly for uncongested heterogeneous networks. Results illustrate that TRAWL has up to a 400% performance improvement over [START_REF]The Network Simulator NS-2 NIST Add-on -Neighbor Discovery[END_REF].

This paper is organised as follows; related work is described in section 2. An introduction to neural networks is provided in section 3. In section 4 TRAWL is described. In section 5 and 6 experimental and simulated results are presented. Conclusions and future work is presented in section 7.

Related Work

Many existing MIH implementations utilize a performance threshold P thres to generate the MIH LGD event. In such scenarios the relationship between the time that P thres (actual or projected) is exceeded, T deg , and the time at which path handover is initiated, T h-init, can be expressed as follows:

) ( deg lg T T d init h α = -
α lgd is an anticipation factor applied to T deg to adjust the aggressiveness of LGD event triggering. Many implementations are based on pre-defined P thres , mostly associated with RSS. If the current RSS crosses P thres the LGD event is generated [START_REF]The Network Simulator NS-2 NIST Add-on -Neighbor Discovery[END_REF]. The NIST MIH implementation in NS2 [START_REF]The Network Simulator NS-2 NIST Add-on -Neighbor Discovery[END_REF] utilizes the power level of packets RXThresh (P thres ) and Pr_limit (α lgd ) to control event triggering. A number of studies utilize a predictive indication of RSS in this manner [3][4]. In [START_REF] Zhang | Link Quality Oriented Proactive Vertical Handover in Heterogeneous Wireless Networks[END_REF] the MN velocity and handover duration are used in conjunction with the predicted RSS level to improve LGD event triggering. While [START_REF] Yoo | Predictive Handover Mechanism based on Required Time Estimation in Heterogeneous Wireless Networks[END_REF][7] use a predictive model which uses the neighbor information to generate timely link triggers so that handover procedures can finish before the link goes down. While these mechanisms utilise metrics which provide a static representation and dynamic view of performance they do not provide a mechanism by which the handover algorithm can tune performance thresholds for changing network conditions.

There are a significant number of recent studies in the area of network handover for vehicle based systems. These studies can be generally categorized in the area of Vehicle Ad-hoc NETworks (VANET) or infrastructure mode network access. Our investigation relates to the latter. In [START_REF] Kumar | SWiFT: A Novel Architecture for Seamless Wireless Internet for Fast Trains[END_REF], SWiFT focuses on handover optimisation for vehicles travelling greater than 200kmph. SWiFT uses the speed of MN movement and RSS as the basis for link event triggering. It does not consider the condition of the link in the handover decision. [START_REF] Hayoung | A Robust handover under analysis of unexpected vehicle behaviors in Vehicular Ad-hoc Network[END_REF] proposes a MIP handover mechanism for VANET which maintains the original Care of Address (CoA) configured at the original AP. [START_REF] Céspedes | An Efficient Hybrid HIP-PMIPv6 Scheme for Seamless Internet Access in Urban Vehicular Scenarios[END_REF] uses Proxy Mobile IPv6 (PMIP) and Host Identity Protocol (HIP) to reduce handover latency for urban vehicular systems. In [START_REF] Fallon | SOLTA: a service oriented link triggering algorithm for MIH implementations[END_REF] we propose multi-homing rather than MIP to pre-configure alternate paths prior to network handover. [START_REF] Ryo | Control of transmission timing using information on predicted movement in opportunistic roadside-to-vehicle communication[END_REF] proposes a collaborative approach in which APs use MN position prediction to limit the potential for retransmission. Such an approach has significant network infrastructure requirements. [START_REF] Chantaksinopas | Framework for network selection transparency on vehicular networks[END_REF] proposes an architecture for network selection in vehicular systems based on network metrics, user requirements and application QoS. We propose that the predictable nature of public transport vehicles enables performance predictability which is not exploited by any of these approaches. Other studies have investigated how network performance can be optimised by predicting network holes [START_REF] Ahmed | The Holes Problem in Wireless Sensor Networks[END_REF] [START_REF] Ghosh | Estimating Coverage Holes and Enhancing Coverage in Mixed Sensor Networks[END_REF]. These studies are ad hoc network based and assume an autonomic approach which allows the sensor nodes to self learn/configure. As an end point oriented solution our approach has no ability to change network configuration.

There are a number of ongoing studies which evaluate how artificial intelligence techniques can be used in the optimisation of network handover. [17] [18] propose a mutually connected neural network in order to optimise load balancing and QoS for the entire network. Our work focuses on the optimisation of throughput for client devices. [START_REF] Rakovic | Novel RAT selection mechanism based on Hopfield neural networks[END_REF] proposes a Hopfield neural network which considers multiple input parameters in the selection of networks. However that study does not consider how the predictable nature of routes used by public vehicles can be used in the optimisation of weights.

Artificial Neural Networks

ANN are data processing models which are based on the operation of the brain. The first work on ANN was presented by Mc Cullock and Pitts in 1943 [START_REF] Mcculloch | A logical calculus of the ideas immanent in nervous activity[END_REF]. The work proposed a Threshold Logic Unit (TLU) which used weighted binary inputs. If the weighted sum of inputs exceeded a threshold value, the neuron fired. Many enhancements to the original model have been introduced. The first unsupervised learning approach, Hebbian Learning, was proposed by [21] in 1949. Classification of inputs was introduced by the perceptron model in [START_REF] Rosenblatt | A comparison of several perceptron models[END_REF]. The introduction of back propagation enabled the training of synaptic weights based on a desired output. This paper proposes TRAWL, an ANN used to capture historic performance trends for predictable route vehicle systems. These trends are weighted against dynamic metrics.

TRAWL -A Traffic Route Adapted Weighted Learning Algorithm

Our TRAWL algorithm consists of 2 components: Route Identification and Management (RIM) -is responsible for the identification and management of vehicle routes. Using the geographical position of the vehicle RIM distinguishes existing, altered or new routes.

Unsupervised Vehicle Learning Algorithm (UVLA) -implements the path selection intelligence within TRAWL. UVLA is a feed forward neural network which operates with a single output neuron for homogeneous networks or 2 output neurons for heterogeneous networks.

Back propagation and weight adjustment are implemented each time the vehicle completes a cycle of a route.

The fig 2 illustrates the pseudo code for the TRAWL algorithm. TRAWL dynamically configures and maintains traffic routes using GPS coordinates. Having read the GPS coordinates, TRAWL determines if the current position uniquely identifies a route. If the position is not previously configured, a new route is created and training is initiated. If the position uniquely identifies a previously defined route, the TRAWL algorithm determines if ANN training is required for that route.

TRAWL operates in either training or trained mode. As an unsupervised algorithm TRAWL does not have an offline training phase. TRAWL uses initial end user synaptic weights to determine if handover is required. Following each route cycle the throughput is calculated and synaptic weights are adjusted. TRAWL is trained when (a) the training process does not update synaptic weights (b) synaptic weight updates have no effect on throughput. TRAWL ensures that synaptic weights remain relevant to changing network conditions by applying an accuracyThreashold. Throughput is measured for every route cycle and if the accuracyThreashold is exceeded training is reinitiated. The ULVA model consists of X 0 , X 1 ,... X n neuron inputs corresponding to the selected performance metrics. Each neuron is a linear threshold gate producing a binary output for path switchover. ˛ is defined as follows:

ˢ I (" ˣ (1) ˛ ŵ ˩˦ ˢ 4 Ŵ ˩˦ ˢ (2)
I { { { { (3)
Using I we can determine the rate by which alterations to synaptic weights affect throughput. A positive I indicates that synaptic weight alterations have a beneficial effect on throughput. A negative I indicates that synaptic weight alterations have a detrimental effect on throughput.

In order to control the rate of learning we define a user configurable learning rate constant J. The selection of an appropriate learning rate is critical for the effective operation of the algorithm. If the learning rate is too low the network learns very slowly. If the learning rate is too high weights diverge, resulting in little learning. We define the error correction, ˣ, as the product of I and J. ˣ I J (4)

An Experimental Analysis of a Commercial Heterogeneous Network Installation

In recent years heterogeneous networking has gained acceptance as the next logical step in wireless and mobile networking. The ITU have formalized this trend through the fourth generation wireless mobile networks (4G) set of standards [START_REF]Framework and overall objectives of the future development of IMT-2000 and systems beyond IMT-2000[END_REF]. Many mobile operators are embracing heterogeneous networking. Initiatives such as the TeliaSonera Homerun and British Telecom's OpenZone [START_REF] Heikkilä | Business Models of Mobile Operators for WLAN: Case Examples[END_REF] have made heterogeneous networking a reality. In this section we analyze the performance characteristics of one such commercial deployment.

Simulated Evaluation of the TRAWL Algorithm

In this section, we evaluate the performance of TRAWL for the network configuration described in Section 4 using NS2 with the MIH mobility package from NIST [START_REF]The Network Simulator NS-2 NIST Add-on -Neighbor Discovery[END_REF]. In order to integrate the geographical location of the route in NS2, we record the GPS coordinates for all junctions. Using these coordinates we simulate a circular route of 4.82km which is traversed in 57 minutes. The intention is to simulate the download of flat file multimedia content, such as advertising, for display on the next route cycle. We recreate the RSS signature illustrated in Figure 5 in our simulated model. We then evaluate our model in congested and non-congested configurations.

Each AP has a transmit power of 0.281838W, transmit antenna gain of 1, receive antenna gain of 1 and an antenna height of 1.5M. This provides an outdoor signal range of approx 250M. The MIH parameters CSThresh (link detection) and RXThresh (link utilisation) were set to -90dBm and -85dBm respectively. Simulation enhancements as described in [START_REF] Palazzi | High Mobility in a Realistic Wireless Environment: a Mobile IP Handoff Model for NS-2[END_REF] were included in the model. The UMTS core network was configured with a 622Mbit link capacity and a delay of 15ms. The WLAN back haul network was configured with a 100MBit capacity and a 1ms delay. The transport layer mobility protocol SCTP was used to implement network mobility. FTP data was then transmitted from the MN towards a back end content server. We evaluate the performance of TRAWL for the configuration illustrated in fig 6 with/without congestion for homogeneous WLAN and heterogeneous WLAN/3G network configurations. In all cases we define the initial weights w 1 =.35, w 2 =.3, w 3 =.4, w 4 =.25 corresponding to the performance metrics loss rate, RTT, RSS and link bandwidth. These weights reflect our initial understanding of the relative importance of each performance metric. The value range .25 to .4 was chosen since values below this size did not result in the stimulation of neurons and hence no path selection occurred. Figs 7, 9, 11 and 13 illustrate the total throughput and synaptic weights for each of the learning cycles. Figs 8, 10, 12 and 14 illustrate the throughput, rate of learning and error correction for each of the learning cycles. Tables 2-5 are based on figs 7-14 and provide a more detailed view of the configuration of TRAWL parameters for each learning cycle. In order to illustrate the operation of the TRAWL algorithm consider rows 1-3 in Table 2. The initial synaptic weights are set as described above. At routine intervals, at least once per second, the performance metrics loss rate, RTT, RSS and link bandwidth are recorded and normalised. These normalised values are multiplied by the initial synaptic weights. If the summation of these values exceeds the activation threshold switchover occurs. On the first cycle of the route this approach resulted in a throughput of 66.82Mbytes. A slope of a line from the origin to the point (1,66.82) is calculated resulting in a slope of 66.82. This slope is then multiplied by the learning rate, .002, resulting in a weight adjustment of 0.13364. On the second cycle the synaptic weights w 1 =.484, w 2 =.3, w 3 =.4, w 4 =.25 result in a throughput of 164.9Mbytes. We calculate the slope of a linear regression line through the points (0,0), (1,66.82), (2,82.45) as 82.45. Multiplying the learning rate .002 by 82.45 results in a synaptic weight adjustment following the second cycle of .1649. Weights are adjusted in this manner following every cycle until the slope of the linear regression line is 0 or until adjustments in the synaptic weights have no effect on throughput.

Local maxima can have a negative effect on ANN performance as learning is centred on a local maximum value. Table 1 illustrates the TRAWL parameters for learning cycles 5-10 for the non congested heterogeneous network. After 9 cycles the slope of the throughput linear regression is 0 indicating that no error correction is required. The synaptic weight configuration w 1 =.575, w 12 =.518, w 3 =.590, w 1 =.516 has been optimised around a local maximal value. In order to avoid local maxima we introduce a positive or negative random weight adjustment in the range 0-0.2 every 5 learning cycles. In cycle 10 the random weight adjustments w 1 =.-.112, w 12 =-.181, w 3 =.-.069, w 1 =.-.145 are applied avoiding the local maxima and resulting in the final trained throughput of 74.4Mbytes. In Section 2 we described the mechanism used in [START_REF]The Network Simulator NS-2 NIST Add-on -Neighbor Discovery[END_REF] to implement the MIH LGD event. Table 6 compares the performance of [START_REF]The Network Simulator NS-2 NIST Add-on -Neighbor Discovery[END_REF] against a fully trained TRAWL. Table 6 illustrates that when TRAWL is fully trained it has significantly better performance than [START_REF]The Network Simulator NS-2 NIST Add-on -Neighbor Discovery[END_REF] for MIH LGD event triggering, particularly for a non congested homogenous WLAN configuration. In order to explain the significant performance differential we consider fig 5 in more detail. For a commercial heterogeneous network implementation where APs are positioned for hot spot coverage, RSS ranging for -80dBm to -90dBm is common. The average RSS for this installation was -85.24dBm, ranging from -55dBm to -100dBm. -85dBm is considered a point of significant performance degradation in WLAN and RXThresh was set accordingly for the standard MIH approach. By exploiting historic performance trends TRAWL determines that the optimal configuration of weights was w 1 =1.071(loss rate), w 2 =0.895(RTT), w 3 =1.144(RSS), w 1 =.996(bandwidth). Such a configuration gives the following relative performance metric precedence; loss rate 26%, RTT 22%, RSS 28% and bandwidth 24%. While RSS is considered the most important performance metric, the other metrics have only slightly less precedence. Such a weight configuration determines that significant throughput improvement can be achieved at RSS less than -85dBm. For an unsupervised ANN such as TRAWL, learning is performed online. It is critical therefore that the training of synaptic weights is performed with minimal delay. The optimisation of synaptic weights is a trade off between learning time and throughput. 2 illustrate that within 2 cycles, the output of TRAWL is within 1% of its trained value. Table 7 compares the performance of a partially trained TRAWL, 2 learning cycles, against [START_REF]The Network Simulator NS-2 NIST Add-on -Neighbor Discovery[END_REF]. It illustrates that after only 2 learning cycles TRAWL has at least equivalent performance to [START_REF]The Network Simulator NS-2 NIST Add-on -Neighbor Discovery[END_REF].

Conclusions and Future Work

In this paper we proposed TRAWL, a feed forward neural network, which uses the predictable nature of public transport routes in order to optimise MIH link triggering. TRAWL uses an unsupervised back propagation learning mechanism which captures predictable network behaviour while also considering dynamic performance characteristics. We evaluate TRAWL using performance metrics from a commercial heterogeneous network. Results presented illustrate up to a 400% performance improvement over traditional MIH link triggering approaches for this network installation. For an unsupervised ANN such as TRAWL the optimisation of synaptic weights is a trade off between learning time and throughput. While a number of cycles are required to fully train TRAWL, we illustrate that early in the training cycle throughput is close to its final trained value. Future work will extend the TRAWL algorithm to consider metrics applicable to media streaming applications.

Fig 1

 1 illustrates a supervised learning ANN. Values x 0 , x 1 , x 2 ,.... x n are provided as input to the neuron. The neuron has 2 modes of operation; training or trained. In trained mode, the neuron applies synaptic weights w k0 , w k1 ,.... w kn which enhance or degrade the input values. These weighted values are summed and an activation function ϕ(.) is applied. ϕ(.) determines whether the neuron should "fire", producing an output y k which classifies the input pattern.Training mode can be implemented through supervised or unsupervised learning. In supervised learning the ANN will have an offline training phase in which neural outputs are compared against a training set. Alterations are made to the synaptic weights to limit the error in classification between the output y k and the training set d k . When the ANN correctly classifies the input pattern, the ANN operates in trained mode. Unsupervised learning has no external training patterns. In this mode the ANN self organizes data presented to the network and detects recurrent properties.

Fig. 1 A

 1 Fig. 1 A Supervised Learning Neural Network

Fig. 2

 2 Fig. 2 Pseudo code for the TRAWL algorithm

Fig 3

 3 Fig 3 illustrates a UVLA configuration with 2 output neurons for a heterogeneous network with wireless and mobile components.

Fig. 3

 3 Fig. 3 UVLA Neural Network with 2 Output Neurons ˣ are synaptic weights for each performance metric. ˢ is the sum of weighted inputs.is a user configured activation threshold. If the stimulation of the neuron ˢ meets the activation threshold , the neuron "fires" producing a binary positive output. A positive output indicates that path switchover should occur. The aim is to maximise throughput per route cycle, therefore we calculate the rate of change, I, of a linear regression line for historic throughput as follows:

  Fig 4 illustrates the deployment of APs in Belfast city centre for a tourist bus route. Using NetStumbler [25] we record RSS for all APs as illustrated in fig 5.

Fig. 4

 4 Fig. 4 AP Deployment Belfast City Centre Fig. 5 RSS for APs in Belfast City Centre Figure 5 illustrates the RSS received by a MN located on the bus as it follows the route outlined in Fig 4 during a 57 minute circular trip. The average RSS over the duration of the test was -85.24dBm. Figs 4 and 5 illustrate a higher concentration of APs in the city centre. In the city centre the average RSS experienced by the MN was -83.23dBm while in the suburbs the average RSS was -90.2dBm. We use the results of this experimental study as input to the simulated model in Section 6.

  Fig 6 illustrates the topology of the model.

Fig. 6

 6 Fig. 6 Simulated Network Configuration

Fig. 7 Fig. 9 Fig. 11 Fig. 13

 791113 Fig. 7 Throughput and Synaptic Weights for a Fig. 8 Throughput and Error Correction for a Non Congested Homogenous Configuration Non Congested Homogenous Configuration

Fig 7 ,

 7 fig 8 and table

Table 1 .

 1 Local Maxima in a non congested heterogeneous network configuration

	Cycle	w1	w2	w3	w4				Error	Learning
		(Loss)	(RTT)	(RSS)	(Bw)	Thres Throughput	Slope	Correction	Rate
	5	0.582 0.525 0.597 0.523	1	49.15	5.141	0.010	0.002
	6	0.592 0.535 0.607 0.533	1	49.15	-3.939	-0.008	0.002
	7	0.585 0.528 0.600 0.526	1	49.15	-3.89	-0.008	0.002
	8	0.577 0.520 0.592 0.518	1	49.15	-0.928	-0.002	0.002
	9	0.575 0.518 0.590 0.516	1	49.15	0	0.000	0.002
	10	0.463 0.337 0.521 0.371	1	59.38	2.046	0.004	0.002

Table 2 .

 2 TRAWL Parameters for a Non Congested Homogenous Configuration

		w1	w2	w3	w4			Rate of	Error	Learning
	Cycle	(Loss)	(RTT)	(RSS)	(Bw)	Thres Throughput	Change	Correction	Rate
	1 0.350 0.300 0.400 0.250	1	66.82	66.82	0.13364	0.002
	2 0.484 0.434 0.534 0.384	1	164.9	82.45	0.1649	0.002
	3 0.649 0.599 0.699 0.549	1	188.03	66.217	0.132434	0.002
	4 0.781 0.731 0.831 0.681	1	158.49	43.819	0.087638	0.002
	5 0.939 0.853 1.045 0.948	1	166.06	19.207	0.038414	0.002
	6 0.977 0.891 1.083 0.986	1	164.16	-2.345	-0.00469	0.002
	7 0.972 0.886 1.078 0.981	1	164.15	-4.209	-0.008418	0.002
	8 0.964 0.878 1.070 0.973	1	164.16	0.943	0.001886	0.002
	9 0.966 0.880 1.072 0.975	1	164.16	-0.38	-0.00076	0.002
	10 1.071 0.889 1.144 0.996	1	164.18	0.005	0.000010	0.002
	11 1.071 0.889 1.144 0.996	1	164.18	0.008	0.000016	0.002
	12 1.071 0.891 1.144 0.996	1	164.18	0.006	0.000012	0.002
	13 1.071 0.893 1.144 0.996	1	164.18	0.004	0.000008	0.002
	14 1.071 0.895 1.144 0.996	1	164.18	0	0.000000	0.002

Table 3 .

 3 TRAWL Parameters for a Non Congested Heterogeneous Configuration

	Cycle	w1	w2	w3	w4			Rate of	Error	Learning
		(Loss)	(RTT)	(RSS)	(Bw)	Thres Throughput	Change	Correction	Rate
	1 0.350 0.300 0.400 0.250	1	75.44	75.44	0.150880	0.002
	5 0.796 0.722 0.839 0.643	1	70.95	-0.847	-0.001694	0.002
	10 0.641 0.591 0.817 0.560	1	70.89	-0.012	-0.000024	0.002
	15 0.498 0.517 0.799 0.388	1	72.33	0.288	0.000576	0.002
	20 0.568 0.530 0.991 0.528	1	74.4	0.742	0.001484	0.002
	25 0.568 0.530 0.991 0.528	1	74.4	0	0.000000	0.002

Table 4 .

 4 TRAWL Parameters for a Congested Heterogeneous Configuration

	Cycle	w1	w2	w3	w4				Error	Learning
		(Loss)	(RTT)	(RSS)	(Bw)	Thres Throughput Slope	Correction	Rate
	1	0.25	0.2	0.3	0.15	1	20.2	20.2	0.040	0.002
	5 0.582 0.525 0.597 0.523	1	49.15 5.141	0.010	0.002
	10 0.463 0.337 0.521 0.371	1	59.38 2.046	0.004	0.002
	15 0.340 0.200 0.279 0.261	1	59.47 0.063	0.000	0.002
	19 0.340 0.200 0.279 0.261	1	59.47 0.063	0.000	0.002

Table 5 .

 5 TRAWL Parameters for a Congested Homogenous Configuration

	Cycle	w1	w2	w3	w4				Error	Learning
		(Loss)	(RTT)	(RSS)	(Bw)	Thres Throughput	Slope	Correction	Rate
	1	0.25	0.2	0.3	0.15	1	20.2	20.2	0.040	0.002
	5 0.542 0.457 0.485 0.286	1	21.52	-1.904	-0.004	0.002
	10 0.365 0.288 0.284 0.137	1	28.11	1.309	0.003	0.002
	15 0.411 0.321 0.322 0.177	1	35.118	-4.1064	-0.008	0.002
	20 0.406 0.311 0.310 0.174	1	46.4	-3.829	-0.008	0.002
	21 0.394 0.297 0.299 0.162	1	67.89	19.265	0.039	0.002

Table 6 .

 6 Performance Comparison of NS2 MIH LGD and a Fully Trained TRAWL LGD

		NS2 MIH LGD	TRAWL LGD	Performance
		Throughput (MB)	Throughput (MB)	improvement
	Non Congested/Homogenous	41.65	164.18	394%
	Non Congested/Heterogeneous	71.96	74.4	4%
	Congested/Homogenous	42.4	59.47	40%
	Congested/Heterogeneous	44.98	67.89	51%

Table 7 .

 7 Comparison of NS2 MIH LGD and Partially Trained TRAWL LGD (2 Cycles)

NS2 MIH LGD Throughput (MB) TRAWL LGD Throughput (MB) Performance improvement Non Congested/Homogenous

		41.65	164.9	396%
	Non Congested/Heterogeneous	71.96	69.19	-4%
	Congested/Homogenous	42.4	42.09	<1%
	Congested/Heterogeneous	44.98	60.28	134%


Carlos Gañán
email: carlos.ganan@entel.upc.es

Juan Caubet
email: juan.caubet@entel.upc.es

Sergi Reñé
email: sergi.rene@entel.upc.es

Jorge Mata-Díaz

Juan J Alins
email: jalins@entel.upc.es

Óscar Esparza
email: oesparza@entel.upc.es

NeuroCast: Adaptive Multi-Source P2P Video Streaming Application for wireless networks

Keywords: Video streaming, P2P networks, multi-source, wireless

Streaming consists in distributing media to large audiences over a computer network. Providing a streaming service for wireless mobile nodes presents many challenges. A peer-to-peer (P2P) solution has the big advantage of seamlessly scaling to arbitrary population sizes, as every node that receives the video, while consuming resources, can at the same time offer its own upload bandwidth to serve other nodes. In this paper we present the design and implementation of NeuroCast: an unstructured P2P application for video streaming. NeuroCast implements a robust scheduling algorithm which minimizes the scheduling delay. Moreover, given heterogeneous contents, delays and bandwidths. Thus, NeuroCast becomes suitable for wireless scenarios due to its capability to adapt to changing network conditions.

Introduction

During the last decade, the growth of popular web sites serving multimedia contents has led to the increase of video streaming applications. However, video streaming over a wireless network has to deal with several challenges: 1) nothing is guaranteed about bandwidth, delay, and packet loss rate; 2) it is difficult to predict the bandwidth, delay, and loss rate information, since it is unknown and time-varying; 3) the heterogeneity of receiver capabilities is a significant problem when video streams are distributed over a multicast network; and 4) a congestion/flow control mechanism has to be employed to prevent congestion epochs in the wireless network.

There have been proposed several ways to approach these challenges. The traditional client-server model is suitable for streaming, but it presents scalability problems and a loss of efficiency in resource exploitation. In fact, a server has a limit bandwidth and cannot serve more than a limited number of clients at the same time. The best way to distribute multimedia content from a source to a group of hosts at the same time is the IP multicast. However the deployment of IP multicast has been limited due to several reasons. First of all it requires changes in the network devices increasing the complexity and the overhead at the routers. But also, it presents commercial problems since a lot ISPs disable it. Another possibility is to use peer-to-peer networks for the streaming. In these networks, the stream receivers act as clients and servers at the same time (i.e. servent) replicating packets they receive. The aim for these techniques is to allow bandwidth-consuming streaming media to be delivered to a large number of consumers in a scalable, robust and efficient manner. In this sense, we present NeuroCast, a P2P open-source solution to video streaming over wireless networks.

P2P streaming systems strive to optimize three important metrics: i) startup delay, ii) end-to-end delay, and iii) playback continuity index. Most of the systems may be classified based on the type of distribution graph they implement: mainly tree and mesh, though a lot of hybrid solutions have been implemented already. Tree-based overlays implement a tree distribution graph, rooted at the source of the content [START_REF] Deshpande | Streaming live media over a peer-to-peer network[END_REF][START_REF]Peercast: P2p broadcasting for everyone[END_REF][START_REF] Castro | Splitstream: High-bandwidth multicast in cooperative environments[END_REF][START_REF] Rowstron | Pastry: Scalable, distributed object location and routing for largescale peer-to-peer systems[END_REF]. In principle, each node receives data from a parent node, which may be the source or a peer. If peers do not change too frequently, such a system requires little overhead; in fact, packets can be forwarded from node to node without the need for extra messages. However, in high churn environments (i.e. fast turnover of peers in the tree), the tree must be continuously destroyed and rebuilt, a process that requires considerable control message overhead. As a side effect, nodes must buffer data for at least the time required to repair the tree, in order to avoid packet loss. Mesh-based overlays [START_REF] Hefeeda | Collectcast: A peer-to-peer service for media streaming[END_REF][6][START_REF] Zhang | Coolstreaming/donet: A data-driven overlay network for efficient peer-to-peer live media streaming[END_REF] implement a mesh distribution graph, where each node contacts a subset of peers to obtain a number of chunks. Every node needs to know which chunks are owned by its peers and explicitly pulls the chunks it needs. This type of scheme involves overhead, due in part to the exchange of buffer maps between nodes (nodes advertise the set of chunks they own) and in part to the pull process (each node sends a request in order to receive the chunks). Thanks to the fact that each node relies on multiple peers to retrieve content, mesh based systems offer good resilience to node failures. On the negative side, they require large buffers to support the chunk pull, as large buffers are needed to increase the chances of finding the missing chunks in the playback sequence. In this sense, NeuroCast evolves the Peercast [START_REF]Peercast: P2p broadcasting for everyone[END_REF] tree network to a mesh-based overlay.

Peercast is an open source streaming media multicast tool which is generally used for streaming audio and makes use of a bandwidth distributing approach where users can choose the relay to connect in the downstream. NeuroCast extends Peercast in order to enhance its capabilities making it possible to watch videos even in a wireless scenario. Moreover, NeuroCast adds the necessary design to allow any user to become a broadcaster. Among the different improvements made in NeuroCast, it is worth to mention the multi-source streaming capability. In contrast to Peercast, NeuroCast solves the typical asymmetry of the link by using multiple sources. Therefore, it allows to video stream over a wireless network.

In this paper, we first approach the problem of media streaming from a practical point of view. We present the design of NeuroCast, a P2P streaming for wireless networks, that: 1) supports very high levels of churn, 2) supports strongly heterogeneous distributions of peer upload capacity, 3) has multisource capabilities to use efficiently the available upload capacity, and 4) employs fast adaptation and recovery from abrupt changes in network conditions. Due to this fast adaptation, NeuroCast can operate in a wireless scenario where nodes are prone to suffer from disconnections.

The rest of the paper is structured as follows. Section 2 introduces the basics of Peercast. Section 3 describes the NeuroCast system. Section 4 presents a analysis of NeuroCast, carried out by way of emulation on medium-scale network testbeds. Finally, section 5 concludes this work.

Peercast

The multimedia streaming application Peercast is a multi-thread application, so that different processes can be executed at the same time concurrently. The number of processes in Peercast is variable and depends on the amount of connections that are established. The main thread deals with the creation of its child threads. In addition to these tasks, this thread becomes passive waiting for incoming connections. In general, for each request that it receives, a thread is created which will serve the request till its death.

PCP: Packet Chain Protocol

PCP is the protocol used in Peercast to allow communication among different clients. The main goal of this protocol is to reuse the same data-flow which is used to send the multimedia information, to send the control information too. PCP chaining allows users to 'piggy back' a download from another user.

The first packet of a group indicates the type of the packets that are being sent and the number of packets that come after it. These packets that indicate the type of the group are called parent packets. The great potential of this protocol lies in the way the packets are chained, as each one of the packets inside a group can be at the same time parent of another type of packets.

Entities

Peercast uses the Oriented Object programming, i.e., it has several classes that represent the different system entities. Therefore, Peercast consists of servent, channel, buffer and root classes.

Servent. This class becomes essential for the performance of the Peercast application. As any real-time P2P application, the application depends on the network conditions, so the packets can arrive out of order. Hence, it is basic to have a good system to order and store packets efficiently. The servent class manages the channel transmission and listens to requests coming from the network or from the same host. Servents exert the server and the client at the same time. Servents are classified according to the transmission type. Thus, the most used servents are:

-Server: It is the server of the main thread which handles any request. This subclass creates new server classes to manage the different requests.

-Relay: This class manages the retransmission of a channel among different NeuroCast instances. In this mode, the data are sent using the PCP protocol.

-Direct: This class is used to retransmit the multimedia file directly without packing the data. This class is used to handle the packet transmission to a player.

Channel. A channel is originated when a user starts to retransmit new multimedia information to the Peercast network. This user, the first one in uploading the channel to the network, is named the emitter or broadcaster, and it becomes the unique contact between the original source and the Peercast network. The channel is shared among the different peers.

Buffers. It is obvious the necessity of a buffer in Peercast due to the fact that each node can perform as client as well as server, so it needs to store in memory the information in order to be capable of retransmitting it. Without a buffer, a node can only reproduce the received packets in a player but cannot send them to any other client in the network.

Root Nodes. Despite the fact that Peercast was designed to run in a decentralize way, the actual situation is centralized. The developers implemented Peercast in order to create a network without servers. Thus, Peercast only has clients. If a group of users want to share a video among them, they only need to know the IP address of some of them and the channel identifier. Hence, they will create a download tree. On the other hand, if a user wants a video but it does not know any user from the sharing group, that user cannot see the video. Therefore, this situation makes the tree model of Peercast unfeasible for real scenarios. Peercast deals with this issue with the concept of root nodes. For every broadcasting network, one node will act as root, being the primary source of the data flow, while the others will receive it and possibly retransmit it. Root nodes gather information about other clients in order to create an information directory.

NeuroCast

Analyzing the evolution of P2P application for file distribution, it has been noted a leading trend to move from the typical tree/forest topologies to the mesh topology. This evolution allows NeuroCast to use the bandwidth of N users which cannot broadcast the video by themselves, but together they are able to achieve the broadcasting. NeuroCast is a multi-thread application, each network user is able to receive a stream from different peers, and at the same retransmit it to any other user.

Users interact with NeuroCast through a web interface quite simple and friendly. By means of these web pages, the user can manage the application as well as get information about the retransmission taking place or about the peers from where the stream is being downloaded.

Apart from the broadcasters who perform as stream sources, there is another type of clients in NeuroCast: the trackers. These clients deal with the gathering of information about the peers that are sharing a particular channel. Thus, when a user starts a session the tracker will provide to that user a list with the peers that are offering the requested channel. These peers that are sharing the channel are named hits. Therefore, it becomes essential that the trackers have an updated hit list. NeuroCast has been implemented in such a way that all the users perform as trackers. Hence, any peer can share with another their hit list.

On the other hand, using a mesh approach forces us to introduce a new concept: substreaming. Substreaming appears as consequence of the need of receiving a stream from several sources at the same time. In this way, substreaming consists in dividing the original stream in N parts, which are delivered from the different sources that are available following certain criteria that are explained later. Moreover, it could be interesting to receive more packets from one source than from another. Therefore, there are new issues to take care of, such as the arrival packet order or the packet distribution among the available sources. All the packets that the substream consists of are called chunks.

The actions that take place while joining the NeuroCast network are:

-Getting the Hit List. During the initialization, the NeuroCast application connects to the tracker, and it sends back a hit list of the requested channel. -Peer Selection. Once a peer has the hit list, then it has to select the best set of peers from the list. -Packet Allocation. NeuroCast sends the packets grouped in specific chunk numbers which are assigned to the peer transmitting the stream. -Network and load adaptation. NeuroCast monitors the network status permanently while downloading the channel.

Entities

The number of processes in NeuroCast is variable and depends on the amount of established connections. As in Peercast, NeuroCast has a main thread which deals with the incoming requests and creates the children processes that handle these requests. In this section we briefly present the two main NeuroCast entities.

Servent. A servent handles requests from the system and sends the stream either to another NeuroCast instance or to the player. It acts as a server as well as a client. As in Peercast, there exists three different type of servents: direct, relay and server.

Channel. The channels are the main elements in NeuroCast. They are used to handle the different multimedia flows which are being shared in the network. Each flow uses a different channel. NeuroCast only distributes parts of the stream not the whole stream. Every channel has its original source. In general, this source is a user (broadcaster ) who creates the channel and becomes the only physical link among the NeuroCast clients and the original multimedia file. The channel has two main elements.

-The buffer : It manages and stores the incoming packets temporally to allow a retransmission posterior. The maximum number of packets that the buffer can contain is 64. -The channel stream: It deals with the handshaking and the channel reception. Channel stream class allows controlling the incoming packets.

NeuroCast also introduces the possibility of using several peers concurrently, dividing the stream among these, and making the network structure look like a grid. The subchannels are the application elements that allow to identify the stream fragments. Thus, each one of the sources will be associated to a subchannel.

Load balance

As mentioned in the previous section, NeuroCast allows to balance the load according to the network conditions. In this way, NeuroCast implements different algorithms to optimize the peer selection among the hits of the requested channel and the load distribution among the chosen ones. In the following we show how NeuroCast is able to adapt to the network conditions and redistribute the load according to these conditions.

Peers selection. One of the most critical parts in any player based on a P2P network is the selection of peers. Unlike conventional P2P applications for file distribution, the fact of working with video creates a hard and direct dependence on the peers that are transmitting the stream.

Once the hit list has been received from the tracker, it is necessary to calculate which is the subset of peers that will allow to download the stream with the best conditions regarding the network. NeuroCast will always try to prioritize those peers with a high available bandwidth, with the lower packet loss rate, and with a high availability. NeuroCast peer selection algorithm is based in CollectCast algorithm [START_REF] Hefeeda | Collectcast: A peer-to-peer service for media streaming[END_REF]. The strengths of this algorithm are the sources selection, the network status monitoring and the periodic source redistribution in order to adapt to the time-varying network conditions. The selection process can be split up into three phases:

1. Obtaining the hit list associated to the requested channel. 2. Enumerating the sets of hits that satisfy the constraints imposed by:

R l ≤ P = Pact Rp ≤ Ru, (1)
where Rp is is the maximum sending rate that a peer can contribute anytime during the session, Rl is the lower limit of the total sending rate of a set of peers, and Ru is the upper limit of the total sending rate of a set of peers. 3. Selecting the best set of peers among the solutions obtained previously.

When requesting a new channel, NeuroCast obtains a set of parameters from each source. Thus, the requesting peer obtains the peerRp of each source, i.e., the maximum sending rate that a peer can contribute with. Then, NeuroCast calculates the throughput and the losses of the link with each one the hits. In order to do these measurements, NeuroCast takes advantage of a modified version of the Iperf [START_REF] Tirumala | Iperf: The (tcp/udp) bandwidth measurement tool[END_REF] application.

Apart from the bandwidth that a specific peer is willing to share, it is also interesting to know the availability of the set of hits. In any P2P network, it is impossible to determine the expected lifetime of the network, as it is not possible to predict when a node will be disconnected from the network, or the congestion of the network with the subsequent massive packet loss. A possible implementation to calculate the availability in our environment is carried out in the following way. A parallel process to NeuroCast runs to check the status of the hits during a limited period of time. With these measurements, it is generated a probabilistic function for each instant of the day, allowing to know the probability that a peer is connected at that time.

Packet Allocation. Unlike the CollectCast algorithm, in this first version of NeuroCast the final application is simplified and does not use FEC codes to distribute the load among the different hits that have been selected to retransmit the channel.

The active peers ( Pact) collectively send the media file segment by segment: they all cooperate in sending the first segment, then the second one, and so on. The media file is divided into equal-length data segments. Peer p is assigned a number of packets Dp to send in proportion to its actual streaming rate:

Dp = ∆ • Rp x∈ Pact Rx . ( 2
)
where ∆ is the size of original packets in which the media file is divided into. The Dp value is used to distribute the chunks among the different peers of the set. Delta is the number of chunks into which the stream is divided in order to work per groups with subchannels.

Network adaptation. To accommodate the maximum load of the network, NeuroCast adds a new functionality so that it is able to adapt at any moment the number of chunks that a peer is downloading. The variable used to determine the most appropriate chunk-distribution is the time between arrivals of packets. Thus, controlling the time between packet arrivals during the session, NeuroCast sets a threshold that allows to redistribute the number of chunks that each peer retransmits. This threshold is calculated following next equation:

threshold = buf f er length bitrate
• F ACT OR SEP P ACKET S • numChunks numSubChannelChunks .

(3) As seen in equation 3, the threshold depends on different parameters:

1. It depends on the bitrate of the played video. 2. The FACTOR SEP PACKETS (maximum allowed delay between packet arrivals). 3. numChunks is related to the number of chunks into which the stream is divided among the different hits. 4. The numSubChannelChunks is the number of chunks that this subchannel retransmits. To alert the rest of hits of the load redistribution the requesting peer sends to each one of the hits the message CHANGE PEER CHUNKS through it. Next, a NeuroCast server in the target machine reads the request and enables the flag associated with the redistribution, so that the Relay server that broadcasts the channel is ready to receive.

Once the subchannel is ready for the load redistribution, the peer performs the following steps:

1. Notifies the others subchannels about the redistribution. 2. Decreases by one the number of chunks that is downloading from its hit. 3. Searches for a subchannels with a lower time between arrivals in order to send the chunk it has you just subtracted. 4. Waits until the subchannel with lower time between arrivals has redistributed the chunks. Once the rest of subchannels have been informed that a load redistribution is going to take place, they also enter into the of redistribution. At this point, two different situations must be distinguished: on one hand the subchannels with lower time between arrivals and on the other hand the rest of subchannels. The latter simply expect that the redistribution is done, to continue with the download of the new allocated chunks.

And regarding to the subchannel with the lowest time between arrivals, it follows these steps:

1. Checks that the channel has more than one subchannel currently. If that hit is the only active subchannel it must start to download the full stream from that hit. 2. If there are more subchannels, it increases by one the number of chunks of the subchannel. 3. Finally, it redistributes the load among all the hits from the list according to their number of chunks. A different case from the one presented above, but that also requires load redistribution occurs when a peer does not receive packets from a certain subchannel. In these situations the load redistribution is forced immediately.

Another of the new features that have been introduced in NeuroCast is to get rid of the hits that are only sending a single chunk, and despite that, they still send packets with delay. In these cases, the peer removes that hit from its list of hits and downloads the latest chunk from another peer, leaving the subchannels on standby until the channel becomes unavailable or it decides to leave the network.

Performance Evaluation

In this section, we present emulation results by which NeuroCast capabilities are evaluated. Two different environments are configured in order to check NeuroCast's performance in heterogeneous network conditions. The reference scenario for our emulations is created using VNUML [START_REF]Virtual network user-mode-linux[END_REF] as shown in Figure 1. In this virtual network, the Host serves the video to E0, and the latter sends the stream to 3 machines (E1, E2 and E3). The main features of the virtual network and the virtual machines are shown in Table 1. Using this configuration, we change the network conditions where these peers are operating to recreate two different environments. These environments will emulate the conditions of a peer operating in a wireless network.

Impact of topology changes

In a wireless scenario, it is common to have highly changing topologies. In this section, we evaluate how NeuroCast achieves to adapt to these changing conditions without disrupting the quality of the multimedia service. Thus, when downloading a video from more than one source, if one of these sources leaves the network, then the requesting peer redistributes the load and continues downloading the subchannels from other sources. The process that takes place consists in:

1. Checking if there is a free peer in the cached list of hits. That is, a hit from which the peer is neither downloading any chunk nor sending any part of the stream. 2. Requesting a new list of hits to the tracker and check again if there are any free hits. 3. Downloading the "missing" chunks from one of the hits that the peer is already using.

In the latter case it requires a reallocation of subchannels. Depending on the situation, NeuroCast carries out a series of changes:

-If the client is downloading more than one subchannel from the same hit, then it groups the chunks in the same subchannel. -If a subchannel that is not at the end of the list is deleted, then this position is filled with the last subchannel, so there are no empty spaces in the list. -If a subchannel downloads all the chunks into which the stream is divided, then the value of numChunks is set to 1 and the stream is no longer divided into different parts.

Next, we show an example of a peer leaving the network. Initially we have the following configuration (see Table 2): Table 3. New List of Hits and final chunks distribution among 2 subchannels.

As the only new addition to the list of hits is its own IP address, it has only the possibility of reusing the hits which were already transmitting the stream. In this example, as shown in Table 3 it is selected the 10.0.1.2 peer. Summarizing, NeuroCast is able to adapt to any change in the topology of the network no matter if the peer has left because it lost connectivity or because it decided to stop streaming.

Impact of traffic interferences

Another situation that is prone to happen in a wireless scenario is to suffer interferences from another peer in the network. To show how NeuroCast works under these conditions, continuing with the network topology of figure 1, we evaluate the situation where we have 4 machines running NeuroCast and playing a video: Host, E0, E1 and E2. As we have seen in previous cases, in a "stable" situation machine E0 downloads the stream from Host, machine E0 downloads it from E1, and finally E2 downloads it from E0 and E1 simultaneously.

In this section, we focus on studying the performance of machine E2 while suffering from traffic interferences. To achieve that environment, we introduce traffic interference in link N et1 using Distributed Internet Traffic Generator (D-ITG) [START_REF] Avallone | D-itg distributed internet traffic generator[END_REF] in E3.

Prior to the injection the traffic interference, E2 is downloading 6 chunks from each source as the conditions of N et1 and N et2 are virtually identical. However, when we introduce a traffic of 800 kbytes/s in N et1 link, this balance is broken. Thus, chunks coming from the E1 are affected, and consequently, the time between packet arrivals is increased. Precisely this is reflected in the graphs of figure 2(a) and 2(b).

Figure 2 shows, apart from the mean time between packet arrivals, the theoretical limit that the program uses to determine when a redistribution of chunks is necessary. It is worth noting that the redistribution occurs when that limit is exceeded 3 times, because this is the value of the parameter delay margin defined in the NeuroCast configuration file running in E2.

As we have seen previously, some parameters in the configuration file directly affect the behavior of the application during variations of the network conditions. In the following we carry out several setups, varying two parameters such as delta and buffer sep packets, and we observe in each case the time needed to redistribute the chunks. To force the redistributions, we use Network Emulator (NetEm) [START_REF] Hemminger | Network emulation with netem[END_REF] to change the link capacity of one of the hits that is retransmitting the stream. Thus we switch from the 1000 Kbps available at the beginning of the session, to 112 Kbps. Analyzing the results in Table 4 we observe that the parameter Delta, i.e. the number of chunks into which the stream is divided, does not affect significantly the obtained time, while the parameter buffer sep packets is decisive. 4. Performance with a traffic interference of 90% of the link capacity.

Consequently, as it can be inferred from these results, any peer running NeuroCast even while suffering from interferences is able to operate without major quality of service degradation.

Conclusions

P2P technology gives novel opportunities to define an efficient multimedia streaming application but at the same time, it brings a set of technical chal-lenges and issues due to its dynamic and heterogeneous nature. We must make a balance between the breadth and depth of a live streaming overlay tree. At the same time, the robustness issue must be considered carefully, as the dynamic feature and freedom of P2P network itself. In this this work we have presented the implementation of NeuroCast, an unstructured P2P system for video streaming that is able to adapt to wireless network conditions. Neuro-Cast design is based on an unstructured mesh-based architecture. It intends to optimize bandwidth allocation and combine dynamic peer selection strategies that rely on implicit feedback from data reception.

NeuroCast's performance is evaluated in emulated network environments. The experiments indicate that NeuroCast is capable of operating in a harsh environment taking into account network conditions. Our results also confirm the ability of unstructured mesh-based systems to withstand the high levels of transience that can result from user and network dynamics (churn, failures, congestion, etc.).

Fig. 1 .

 1 Fig. 1. Network topology used for the tests.

Fig. 2 .

 2 Fig. 2. Mean time between packets arrival evolution.

Table 1 .

 1 Initial parameters of the virtual network and the virtual machines.

			Host	E0	E1	E2	E4
		maxRelays	1	4	4	4	4
	Type Net0 lan 2 Mbps Bw Net1 ppp 1 Mbps Net2 ppp 1,5 Mbps Net3 ppp 750 Kbps	peerRp minRp delta factor sep pack delay margin buffer sep pack	2 Mbps 1 Mbps 1 Mbps 700 Kbps 1 Mbps 100 Kbps 100 Kbps 100 Kbps 100 Kbps 100 Kbps 0 10 10 10 15 1 1.3 1.3 1.3 1.3 0 4 4 4 3 0 30 30 30 16
		Rl	100 Kbps 100 Kbps 100 Kbps 100 Kbps 100 Kbps
		Ru	2 Mbps 2 Mbps 3 Mbps 3 Mbps 3 Mbps

Table 2. Initial List of Hits and chunks distribution among the 3 subchannels.

After some time, source 10.0.0.2 leaves the network. The requesting peer checks that there are no-free hits in its hit list, so it requests a new hit list to the tracker (see Table 3).