Pratibha Mitharwal

Christophe Lohr

Annie Gravey

Survey on Network Interface Selection in Multihomed Mobile Networks

This survey is focused on providing a cruising ship with Internet access facilities. On a ship, the entire network infrastructure (networks, subnets, devices, terminals, etc.) is subject to mobility. Multiple connections (e.g., satellite, LTE, 3G, WiFi, etc.) can provide Internet access, thus making the ship multihomed, but the different connections may be sporadic, and provide different services in terms of bandwidth, throughput, cost. The user may thus need to dynamically select one connection among those that are available, according to its preferences. This paper presents a survey of network interface selection in existing mobility and mutlihoming protocols to provide multihomed network mobility to a cruising ship, or to any vehicle (e.g., train, car, airplane, etc.).

Introduction

In early days computers were very heavy to move around and had only one interface. Therefore, it was easy to identify any computer with a single Internet address. With the evolution of technology, computers can be easily moved around (i.e., they are mobile) and are connected through several network interfaces simultaneously (i.e., they are multihomed). Mobility and multihoming are closely related to each other with respect to IP addressing. Concerning mobility, IP address changes due to changing network attachment point (location) of the host (interface), whereas in multihoming, IP addresses change while changing communication paths (the selected network interface). Changes in IP address cause connection disruption as upper layers sockets are bound to IP addresses. Multihomed mobile hosts such as smartphones, tablets etc. commonly use a single link at a given time. The network selection for every data connection on such technologies is based on "the best availability" or "on user choice". These two choices do not provide the user with cost effective benefits of multihoming scenario, e.g., one link may be free of charge but with a poor connection while another may provide dedicated services, a managed quality of service, etc., and be costly with a specific cost scheme (by volume of data, time of the day, distance, etc.). Similarly, in multihomed mobile networks (e.g., train, ship, airplanes etc.), there are many users and every user will have different requirements. These user requirements (influenced by user & application preferences) and network characteristics (e.g., price, bandwidth, quality etc.), can be used to select the best available interface. If the interface selection is done appropriately it can improve the performance of network applications [START_REF] Ben Nacef | A generic end-host mechanism for path selection and flow distribution[END_REF]. Interface selection mechanism combines two steps: taking the decision on interface selection, and enforcing the decision. In mobile networks, the decision enforcement is located at the edge router (i.e., mobile router) of the network. Therefore, a interface selection mechanism which can communicate with the users and the mobile router, is required. During mobility, the availability of network interfaces and also the characteristics of access networks are constantly changing as the system moves. Whenever this happens, one may want to transfer the ongoing communication from one network interface to another interface. Multihoming uses same scenario to provide best available connection. This paper discusses about network interface selection mechanism in the existing protocols for mobility in multihomed context. The remainder of the paper is organized as follows. In Section 2, we explain about the project and requirements. Section 3, explains functionality of multihomed mobility protocols with provided interface selection mechanism (if any) and Section 4 concludes this paper.

Context of Study & Requirements

This study is part of TMS (Terminal Marine Stablisé) project1 , which aims to design a ship terminal facilitating broadband access for cruising ships. The major requirements of this project are explained in following subsections. An overview of all these requirements is given in Table 1.

Mobility

Mobility refers to a situation where an end-host changes its topological point of attachment to the Internet. Whenever a host moves, its network layer address changes. Thus, in order to continue to communicate, the host must be able to signal the changes in its addresses to its active peers. This signaling must be secure since non-secured signaling can lead to an unauthorized traffic diversion and denial-of-service attacks. If end user hosts are mobile it is considered as "host mobility", and if border routers and interconnected edge network hosts are mobile it is considered as "network mobility".

Requirement R1: Network Mobility First requirement for TMS project is, network mobility management. The network mobility management [START_REF] Eddy | At what layer does mobility belong? Communications Magazine[END_REF][START_REF] Le | A review of mobility support paradigms for the internet[END_REF] needs to provide support for handover management to forward the packets towards new location for an ongoing communication imposing minimal disconnection time for reducing unacceptable data loss, reachability to mobile network's new location, support for existing applications and services without any change, transparency to user applications about mobility, minimal infrastructure changes, roaming agreement and authentication process while switching network interfaces between different operators to avoid security concerns, e.g., address stealing, address flooding which cause Denial-of-Service, man-in-middle etc. In TMS project, mobile networks are ship based where network changes does not happen too often, so handover speed is of minor interest.

Multihoming

Multihoming refers to a situation where an end-point has several parallel path for communication with rest of the Internet [START_REF] Hurson | Connected computing environment[END_REF]. This situation can be characterized as the host being reach-able through several topological paths (with multiple network layer addresses) which are completely independent of each other. When a host is connected with several different edge networks it is known as "host multihoming", and when an edge network is interconnected to the core redundantly with multiple connections via multiple borders or via multiple interfaces of a border router it is known as "site multihoming".

Multihoming helps to achieve redundancy and fault tolerance, increase bandwidth, balance the load inside the access network and provide traffic engineering by stripping the flows over all existing paths, using user defined rules [START_REF] Mihailovic | Providing multi-homing support in ip access networks[END_REF].

Requirement R2: Multihoming Second requirement for TMS is multihoming management. The multihoming solutions [START_REF] Wakikawa | Goals and benefits of multihoming draft-ernst-generic-goals-and-benefits-01[END_REF] needs to provide support for interface selection mechanism required when a communication is established (e.g., when a TCP connection is opened for an outgoing & incoming traffic), a secure recovery mechanism for handover management and session continuity to divert ongoing communication from one interface to another in case of failure with minimal delay, a mechanism to handle growth of routing tables in case of aggregated routes, a mechanism to handle change of traffic characteristics, and a mechanism for controlling the load balance (symmetric flow of packets across all existing paths) based on address assignment.

Interface Selection

Interface selection refers to the selection of source IP address among all existing interfaces for a connection association or indirectly selection of first hop router influenced dynamically by user application preferences. In mobile networks, user's participation can play an important role in interface selection as shown in [START_REF] Boutet | Advantages of flow bindings: an embedded mobile network use case[END_REF]. However, this experiment is done considering static scenarios. In interface selection mechanism first step would be to specify interfaces that can be used on account of a user/application's, operator's or peer node's requirements. Then, a policy set is created prioritizing the interfaces based on policies.

A policy set contains filtering rules which can be stored as table distribution mechanism [START_REF] Matsushima | Ipv6 multihoming without network address translation[END_REF] or database [START_REF] Ylitalo | Dynamic network interface selection in multihomed mobile hosts[END_REF]. After the policy set is created, these filtering rules can be used as input at OS level filtering frame work such as APIs, which will then enforce the decision in packet routing.

Requirement R3: Interface Selection Third requirement for TMS project is Interface selection which can be divided into static interface selection (R3S) and dynamic interface selection (R3D). Static interface selection can be managed by putting some filtering rules in OS whereas the management of dynamic interface selection is a challenge in multihomed mobile networks due to frequent changes of topological location of interface, changes in application requirement or change in availability of access, so it requires a way to manage these operations. Dynamic network interface selection decisions lie on the various information such as user preferences, application requirements, hardware capacity, available network's characteristics, service provider's constraints, network administrator preferences etc. [START_REF] Ylitalo | Dynamic network interface selection in multihomed mobile hosts[END_REF]. So there is a need for decision modules which will have all the available information from link layer (network signal quality and related metrics), several attributes like source address destination address from IP layer, information about cost, bandwidth and availability of Internet access from network service provider (and constraints if any), information originated from user & applications etc.

Multihomed Mobile Networks

There exists several proposals on how to take decisions with respect to interface selection and most of them follow the policy filtering rules. Some approaches use Multiple Attribute Decision Making (MADM) algorithms for decision making about best available network, such as Analytical Hierarchical Process (AHP) [START_REF] Saaty | How to make a decision: the analytic hierarchy process[END_REF], Grey Relation Analysis (GRA) [START_REF] Song | A network selection mechanism for next generation networks[END_REF] and Technique for Order Preference by Similarity to Ideal Solution (TOPSIS) [START_REF] Triantaphyllou | Multi-criteria decision making methods[END_REF]. A MADM algorithm first creates a decision matrix by measuring values of each criterion and then the effect of parameters scales and units is eliminated by normalization. Next the final decision scores are calculated to take the decision. An architecture is proposed in [START_REF] Suciu | Towards a highly adaptable user-centric terminal architecture[END_REF] for automatic network interface selection and allow user to stay connected with best available access network. The selection decision algorithm uses classical weighting objective method for decision making, considering multiple network and application preferences in account. The interface selection module for multihomed mobile hosts based on policy management and flow distribution were proposed in [START_REF] Ben Nacef | A generic end-host mechanism for path selection and flow distribution[END_REF][START_REF] Mitsuya | A policy management framework for flow distribution on multihomed end nodes[END_REF][START_REF] Shen | Policy based mobility & flow management for ipv6 heterogeneous wireless networks[END_REF][START_REF] Suciu | Towards a highly adaptable user-centric terminal architecture[END_REF], but none is standardized. The following subsection details about the dynamic enforcement of interface in various network and transport layer multihomed mobility protocols.

A. Gravey, Y. Kermarrec (Eds.) 4 EUNICE 2014

MULTIHOMED MOBILE NETWORKS

Mobile IP with Extensions

Mobile IP is a network layer protocol, which enables mobile host to leave its home network and continue to receive packets at its home address irrespective of its current location. Each mobile host is identified by its home address. A new entity called home agent (HA) is introduced , which is a router at a static location in the host's home network for supporting mobility services. HA intercepts the packets destined to mobile host's home address when it is away. The idea was standardized for IPv4 (Mobile IPv4, MIPv4) in RFC 3344 [START_REF] Perkins | Ip mobility support for ipv4[END_REF] and IPv6 (Mobile IPv6, MIPv6) in RFC 3775 [START_REF] Johnson | Mobility support in ipv6[END_REF]. The protocol offers transparent movement of a mobile host to transport layer protocols and applications.

When the host moves to another network, it acquires a new address called a care-of address (CoA) through either stateless or stateful auto-configuration.

The mobile host then informs the home agent of its current address. A binding is created between mobile host's home address and care-of address. Any host communicating with mobile host is known as a corresponding node (CN). The CN uses the mobile host's permanent home address (belongs to the network associated with HA) as the destination address. Normal IP routing mechanisms forward these packets to the home agent. HA then redirects these packets to care-of-address through the IP tunnel by encapsulating the datagram with a new IP header using the care-of address of mobile host.

Hierarchical Mobile IPv6 (HMIPv6) was defined in RFC 5380 [START_REF] Soliman | Hierarchical mobile ipv6 (hmipv6) mobility management[END_REF], is an extension to MIPv6. It aims to improve performance of MIPv6 by reducing signaling traffic and by optimizing delays that are introduced by binding updates.

There is another extension for fast handover in MIPv6 [START_REF] Koodli | Mobile ipv6 fast handovers[END_REF] to reduce handoverlatency.

Proxy Mobile IPv6 (PMIPv6), specified in RFC 5213 [START_REF] Gundavelli | Proxy mobile ipv6[END_REF], extends MIPv6 signaling and reuses many concepts such as the home agent functionality. It is a network based mobility management solution which frees mobile host from participating in any mobility related signaling. The proxy mobile agent in the serving network performs mobility related signaling on behalf of mobile host. However, this protocol does not support multihoming.

Network Mobility (NEMO) Protocol was specified in RFC 3963 [START_REF] Bernardos-Cano | Nemo: Network mobility in ipv6. IPv6 More than A Protocol[END_REF][START_REF] Devarapalli | Network mobility (nemo) basic support protocol[END_REF]. NEMO basic support also extends the idea of MIPv6 to support connectivity of network which moves. It contains a mobile router which is in charge of the mobility operation on behalf of all the hosts located in the moving network. In order to fulfill requirement R1, NEMO ensures session continuity and reliability into a mobile network while moving transparently to the mobile network nodes(MNNs) with help of mobile router (MR). The mobile router works as a normal IPv6 router in its home network, i.e., routes all the traffic using traditional routing methods. When mobile router is connected to another IPv6 network it acquires a care-of-address (CoA), which represents its current location in the Internet. Then mobile router like mobile host in MIPv6, registers care-of-A. Gravey, Y. Kermarrec (Eds.) 5 EUNICE 2014 address to its home agent (a router located in mobile router's home network). Whenever mobile router is away from home network, home agent maintains the binding between home address, care-of-address and the prefix advertised in the mobile network (known as mobile network prefix (MNP)). A bi-directional IPv6in-IPv6 tunnel is used to maintain connectivity between mobile router and home agent.

Multiple care-of addresses registration (MCoA) is an extension for MIPv6 and NEMO that was standardized in RFC 5648 [START_REF] Wakikawa | Multiple care-of addresses registration[END_REF]. In MIPv6 and NEMO careof-address is a single point of failure for the whole network, so MCoA mechanism allows multiple care-of-addresses registration with mobile host's or network's home agent. In MCoA, a new binding identification (BID) generated by mobile host/router for each care-of-address, is used as unique key to distinguish multiple bindings that are registered by the same mobile host. The home agent caches the received binding identifications in a binding table and is therefore able to distinguish the multiple care-of-addresses of the mobile host/network. MCoA enables Mobile IPv6 and NEMO to support multihoming, which fulfills requirement R2.

Flow binding is also an extension for MIPv6 and NEMO that was standardized in RFC 6089 [START_REF] Tsirtsis | Flow bindings in mobile ipv6 and nemo basic support[END_REF] which allows hosts to bind one or more flows to a care-of address. These extensions allow multihomed hosts to instruct home agents and other Mobile IPv6 entities to direct inbound flows to specific addresses. In flow binding extension user can define any policies at OS level (fulfills R3S), but not in real time. It is assumed that the policies are configured on the mobile host's packet filtering tool [START_REF] Ropitault | Implementation of flow binding mechanism[END_REF] and the rules specified by the user are according to interface and binding, so the rules are protocol specific [START_REF] Mitsuya | A policy management framework for flow distribution on multihomed end nodes[END_REF].

Location Independent Network (LIN6)

LIN6 [START_REF] Teraoka | Lin6: A solution to multihoming and mobility in ipv6[END_REF], follows the idea of identifier and locator separation [START_REF] Kunishi | Lin6: A new approach to mobility support in ipv6[END_REF]. It introduces an identifier for each host known as LIN6 ID which is independent of its location and interfaces. It also defines two types of network addresses: the LIN6 generalized ID and LIN6 address. The LIN6 generalized ID is formed by concatenating a constant value called the LIN6 prefix before the LIN6 ID which is used at the transport layer to identity the connection. Whereas, the LIN6 address is formed by concatenating the network prefix (changes according to the mobile host's current network) and LIN6 ID which is used to route packets over network layer. The generalized IDs are then stored into DNS, together with the address of a mapping Agent. Since the generalized IDs are globally unique and permanent, the communicating hosts use them as endpoint identifiers. Apart from this, a mapping agent is used in LIN6 for queries related to mobile host's current address. LIN6 also supports multihoming through a single GI to be associated with several real addresses (fulfills R2). There is no explicit way for interface selection mechanism in LIN6 for multihomed mobile hosts.

A. Gravey, Y. Kermarrec (Eds.) 6 EUNICE 2014

MULTIHOMED MOBILE NETWORKS

Locator Identifier Separation Protocol (LISP)

LISP achieves site-multihoming through core-edge separation and provides endto-end packet delivery [START_REF] Farinacci | The locator/id separation protocol (lisp)[END_REF][START_REF] Iannone | Implementing the locator/id separation protocol: Design and experience[END_REF][START_REF] Saucez | Designing a deployable internet: the locator/identifier separation protocol[END_REF]. It follows three simple principles: address role separation, encapsulation, & mapping. To achieve first principle, LISP splits the semantics of IP addresses into endpoint identifiers (EID) and routing locators (RLOC). RLOCs are assigned to border routers by ISPs and EIDs are assigned inside edge networks. In LISP, the packets are created with EIDs in source and destination addresses, then these are encapsulated in a UDP segment with LISP header and finally forwarded through tunnels between edge networks. Border routers of the packet source are known as ingress tunnel routers (ITR), which perform encapsulation and the border routers of the destination site are known as egress tunnel routers (ETR), which perform the decapsulation. A mapping system (like DNS) is created for the mappings between EIDs & RLOCs. LISP's tunnel routers can query the mappings for specific EIDs and the system returns all the related mappings. LISP provides improved traffic engineering capabilities and multihoming (fulfills R2). LISP mobile host [START_REF] White | Lisp mobile node[END_REF] receives an EID from its home network and an address inside foreign network which can be used as RLOCs. Whenever mobile host moves and its RLOC changes, it registers the new mapping into the map server of its home network. LISP extension for network mobility (fulfills R1) has been proposed in [START_REF] Coras | Lisp network element deployment considerations[END_REF]. This locator identifier split can improve Internet scalability but it has deployment constraints. LISP does not provide any interface selection mechanism considering user preferences.

Host Identity Protocol

Host identity protocol (HIP) [START_REF] Moskowitz | Host identity protocol architecture[END_REF][START_REF] Moskowitz | Host identity protocol[END_REF][START_REF] Nikander | Host identity protocol (hip): Connectivity, mobility, multi-homing, security, and privacy over ipv4 and ipv6 networks[END_REF] has been developed to solve security, mobility and host multihoming issues in an integrated concept. It separates host identification & location, and introduces a new namespace, namely the host identity (HI). The purpose of HI is to support trust between systems, enhance mobility, and greatly reduce the DoS attacks to provide better security than other multihomed mobility solutions. HIP introduces a new host identity layer (layer 3.5) between the IP layer (layer 3) and the upper layers to avoid a dual role of IP address as endpoint and forwarding identifier. In HIP, upper layer sockets are bound to HI instead of IP addresses. In addition, the binding of these host identities to IP addresses is done dynamically. A great advantage in this mobility solution is that the hosts can easily have both the IPv4 and the IPv6 addresses. Furthermore, there is no need to change the current routing methods. Multihoming (fulfills R2) and avoiding man in the middle(MitM) attacks are the other features offered by HIP. The HIP authenticates the connection and establishes security associations for a secure connection with IPsec ESP. For this purpose it uses a four-way handshake with Diffie-Hellman key exchange. During mobility, HIP protocol is needed to take care of the dynamic binding between the host's IP address and HI as HIs are used to identify the mobile host instead of IP addresses, the location of the host is not bound to the identifier. When one of the communicating peers changes location, it simply sends a HIP A. Gravey, Y. Kermarrec (Eds.) 7 EUNICE 2014 readdress (REA) packet through the secured ESP channel. However, if both of the peers change location at the same time (the double jump problem), a rendezvous server (RSV) is needed [START_REF] Laganier | Host identity protocol (hip) rendezvous extension[END_REF]. RSV is a packet forwarding agent which simply temporarily forwards the initial HIP packet to the responder.

For HIP an interface selection mechanism was defined in shim API [START_REF] Komu | Socket application program interface (api) for multihoming shim[END_REF], which enables participation from applications in interface selection per packet flow basis for both peers (fulfills R3D).

Site Multihoming by IPv6 Intermediation (SHIM6)

The SHIM6 protocol is another multihoming (fulfills R2) host-centric solution [START_REF] Huston | Architectural commentary on site multi-homing a level 3 shim[END_REF][START_REF] Nordmark | Shim6: Level 3 multihoming shim protocol for ipv6[END_REF][START_REF] Rahman | Semo6-a multihoming-based seamless mobility management framework, milcom[END_REF]. It also introduces a new shim sublayer within the IP layer. It supposes that each host in the network owns multiple global IPv6 address. Each IPv6 address can be used as locator for IP routing and identifier or ULID (upper layer ID), for upper layer identification. It also maintains a mapping between locators and ULIDs in all active connections between two hosts. In SHIM6 operation, firstly a normal TCP connection is established between two hosts, then hosts exchange SHIM6 context. At this point, ULIDs and locators have same IPv6 addresses. For failure detection and recovery, SHIM6 uses REAP (REAchability Protocol). In case of any failure, ULIDs will remain same to the upper layers but the underlying locators will change and SHIM6 manages this mapping between locators and ULIDS. Thus the change of locators are transparent to the upper layers. SHIM6 provides denial-of-service (DoS) attack protection to the responder. Although this security measure does not fully preclude the possibility of DoS attacks, at least it imposes an additional effort for the attacker and provides some tracing capabilities.

Interface selection mechanism (fulfills R3D) is defined in shim API [START_REF] Komu | Socket application program interface (api) for multihoming shim[END_REF], which provides applications the liberty to choose preferred locators for both source & destination host and allows to perform per packet flow distribution.

Stream Control Transmission Protocol

Stream Transmission Control Protocol (SCTP) is a connection-oriented protocol for the transport layer [START_REF] Fu | Sctp: state of the art in research, products, and technical challenges[END_REF][START_REF] Stewart | Stream control transmission protocol[END_REF][START_REF] Stewart | Sctp: new transport protocol for tcp/ip[END_REF], similar to TCP, but provides message-oriented data transfer, similar to UDP. It provides reliable transmission control, flow and congestion control same as TCP but offers new features such as unordered delivery, multi-streaming and multihoming (fulfills R2). A key difference to TCP is the concept of several streams (sequence of messages) within a connection which are known as associations. During association startup, a list of IP address-port pairs is provided between the communicating hosts. These addresses are used as the endpoints of different streams. One of the addresses is selected as initial primary path, which is used as destination address for all packets and may be changed later if needed. A host has one primary path and zero or more alternative paths. Alternate addresses are used to retransmit packets when any failure occurs on the primary path. The Dynamic address reconfiguration (ADDIP) [START_REF] Tuexen | Network working group r. stewart internetdraft cisco systems[END_REF] extension for SCTP enables this protocol to add, delete, and change the IP A. Gravey, Y. Kermarrec (Eds.) 8 EUNICE 2014

addresses during an active connection. The SCTP with the ADDIP extension is called mobile SCTP (mSCTP), and provides a seamless handover for mobile hosts that are roaming between IP networks. The protocol is mainly targeted for client-server services, in which the client initiates the session with a fixed server.

For supporting peer-to-peer services, the mSCTP must be used along with an additional location management scheme. SCTP is also incompatible with all old applications.

Being a transport layer protocol, SCTP has the advantage to use security services, offered by the network layer but some vulnerabilities still exist to Menin-the-Middle attacks. Socket API extension for SCTP [START_REF] Stewart | Sockets api extensions for stream control transmission protocol[END_REF] describes about implementing interface selection mechanism (fulfills R3D) but at application level which may not be very efficient.

MultiPath TCP

Multipath TCP [START_REF] Barré | Multipath tcp: from theory to practice[END_REF][START_REF] Handley | Architectural guidelines for multipath tcp development[END_REF] also extends the idea of TCP to add the capability to establish and use multipath between communicating hosts. If the legacy applications want to use all the new features of MPTCP, they would require some changes. The use of an MPTCP socket API being one of them. MPTCP is backward compatible with conventional TCP [START_REF] Scharf | Multipath tcp (mptcp) application interface considerations[END_REF]. The connection establishment in MPTCP begins the same way as in conventional TCP. Signaling messages are used to inform the end user host about MPTCP compatibility. If both endpoints are MPTCP capable and multiple path exists, additional TCP sessions are created on each of the existing path, combining them with existing connection. These additional TCP sessions are also called as sub-flows. In end users network stack applications treat aggregated sub-flows as single MPTCP connection. To exchange available addresses, additional signaling messages are used. Each subflow is identified by a five-tuple compound of source and destination address and port as well as used protocol. Sub-flows can be added or removed also after connection establishment.

MPTCP supports concurrent multipath transfer (fulfills R2) using a packet scheduler which divides the byte stream. The byte stream flows through application into segments and allocates these segments to the sub-flows. At the receiver reordering of these segments can be done using sequence numbers. Congestion control across the sub-flows have been proposed in RFC [START_REF] Scharf | Multipath tcp (mptcp) application interface considerations[END_REF]. Multihoming capability of host can support mobility, i.e., if one path fails (or address changes due to host mobility), other paths will still be available but this is a special case in multihoming scenario. For full mobility support the sub-flow disruption due to address changes must be handled which is not provided by MPTCP.

The MPTCP API [START_REF] Scharf | Multipath tcp (mptcp) application interface considerations[END_REF] contains a minimum set of functions which does not allow a user to express preferences about the management of paths or the scheduling of data.

This paper has surveyed protocols providing (partial) solutions to interface selection and session continuity in the context of a multihomed mobile network. Multihomed mobile networks & host will be connected through different access technologies and access networks, which offer different services in terms of bandwidth, cost, QoS etc. In order to provide the best available network services, the network interface selection should be influenced dynamically by user preferences, policies, service provider's and network administrator's constraints to adapt the real time environment. The filtering mechanism (common feature of all protocols) can help in interface selection by applying specific rules for the flow of packets. The configuration of such rules can be done in two ways, either by using socket API extensions or by relying on inbuilt packet filtering (e.g., NetFilter). A connection socket is identified by associating source & destination IP addresses and ports. The flow binding extensions for Mobile IPv6 and NEMO provide better interface selection mechanism using inbuilt packet filtering at network layer among all surveyed protocols. In HIP and SHIM6, Socket APIs are defined for interface selection.

The SCTP API for interface selection supports path maintenance but does not describe the exchange of filtering rules between peers. NEMO together with 2 NA: Not Applicable its flow binding extension for nearly fulfills all the requirements of our project except dynamic interface selection. Therefore, our next step is to experiment with interface selection using the flow binding extension of NEMO which is dynamically influenced by user-application preferences, network characteristics, service provider's constraints etc. In mobile networks, the interface selection requires a communication between user and mobile router. We plan to implement an API, which can communicate between user/application preferences and network level characteristics. Policy management will also be the part of this API, which will store all the required information from user, application, network, service operator, etc. Having all the attributes we would then design an algorithm to select the best available interface for any packet flow. The last step would be to enforce the decision in real time. We intend to perform feasibility studies of the implemented solutions in terms of scalability, QoS, throughput under various mobility scenarios.

Table 1 .

 1 Requirements of TMS project

	R1: Network Mobility	reachability, session continuity, security, handover, roaming
	R2: Network Multihoming	session continuity, handover, security
	R3S: Static Interface Selection	decision enforcement, binding of packet flows
	R3D: Dynamic Interface Selection	user preferences, service provider's constraints, network administrator preferences

Table 2

 2 summarizes all the multihomed mobility approaches detailed in the previous section. The main results are summarized as:-Locator/identifier separation approaches such as LISP, HIP, LIN6, SHIM6 are promising to solve mobility and multihoming, but come at the cost of modifying end user hosts or of deploying new network entities such as mapping systems or specialized borders as in LISP. -Transport layer approaches as SCTP and MPTCP support concurrent multipath transfer, but do not address mobility and multihoming. -NEMO, together with the MCoA extension, does support network mobility and multihoming but dynamic interface selection is missing.

Table 2 .

 2 Summary of multihomed mobility approaches

	Approach	MIPv6 +Ext NEMO	LIN6	LISP	HIP	SHIM6	SCTP MPTCP
	R3D	No	No	No	No	Yes with (API)	Yes with (API)	Yes with (API)	No

The project is supported by the French Government (Direction Générale des Enterprises)

A. Gravey, Y. Kermarrec (Eds.)

EUNICE 2014


Molham Darwish
email: molham.darwish@telecom-bretagne.eu

Eric Senn
email: eric.senn@univ-ubs.fr

Christophe Lohr
email: christophe.lohr@telecom-bretagne.eu

Yvon Kermarrec
email: yvon.kermarrec@telecom-bretagne.eu

A comparison between Ambient Assisted Living Systems

Keywords: Ambient Assisted Living, Interoperability, adaptability, reconfiguration, distributed access points

The growing number of older people emerges the need to consider autonomy concerns for those people and their need for intensive care. Plenty of researches, such as those in the domain of Ambient Assisted Living Systems, have been carried out to create enhanced conditions for older and people with disabilities, based on providing ICT solutions that enhance the well-being of elderly people and provide them with well independent daily living. In this paper, for better efficiency for such solutions, different essential requirements should be realized to meet those system objectives towards various users. These requirements are identified and introduced. Set of systems has been introduced with their solutions and provided services architecture, to reach the main goal of this work, by evaluating these systems from identified requirements perspective, by studying the functionalities of each system, if they meet the proposed requirements.

Introduction

The number of elderly people will rapidly grow according to the new European population projections for 2008-2060 [1]. This growing number of older people will cause considerable issues for most European countries, since these aging people are living alone and need intensive care. Various researches have been carried out to provide ICT based solutions that enhance the well-being of elderly people and provide them with a well margin of independency in their daily life. Ambient Assisted living (AAL) systems aims to create improved conditions for older people as well as people with disabilities and reinforce the well-being of tem through the use of information and communication technology. These objectives are reached by providing different types of solutions for various users, which aim to enhance the quality of life for aging groups and take care of their health conditions. Therefore, in order to accomplish their objectives, the provided solutions should have specific features that increase systems efficiency towards user expectations. These features could, for instance, provide cost effective solutions with the consideration of user needs involvement, and privacy, as well as considering the participating of all related users, such as caregivers, family members and medical staffs, in the utilization of the system.

The contribution in this work is to identify a set of crucial features for Ambient Assisted Living systems to increase the idealism of these systems towards user needs and expectations, and surveying various projects to investigate what features they maintain in their functionalities, by studying systems architecture, included technologies and provided services.

This paper is organized as follows. Section (2) analyzes and defines the specific features of AAL systems and introduces the main requirements of an AAL system. Section (3) presents number of projects and systems that are developed under various programs and approaches, to provide ambient assisted living services for elderly people and people at home. Section (4) makes evaluation of the proposed systems in section 4, according to the stated requirements defined in section 3. The paper make conclusion in section (5).

Ambient Assisted Living Systems

Recent years, we are seeing the raise of techniques and technologies dedicated to make houses "intelligent", by providing different kinds of devices and services to people with disabilities (due to age or disease), which allow a more comfortable life and better safety [START_REF] Helal | The Engineering Handbook of Smart Technology for Aging, Disability and Independence[END_REF].

Diverse researches have been conducted to use the latest technologies and facilities to enhance the well-being and support the independent living of older people at home, based on the notion of "ambient assisted living" (AAL), by the use of pervasive ICTs to enable the older persons to live autonomously in their own homes [START_REF] Virone | Toward Information Systems for Ambient Assisted Living[END_REF].

The AAL is an approach that aims to create better life conditions for older people and to reinforce the industrial opportunities in Europe through the use of information and communication technology (ICT), by providing more efficient and more productive solutions. According to [START_REF] Jean-Baptiste | A design process enabling adaptation and customization of services for the elderly[END_REF], services provided by AAL systems can be categorized into emergency treatment services, autonomy enhancement services as well as comfort services which significantly improve the quality of life. To develop such a system, users and deployment environments have number of specificities that should be considered when an AAL system is developed, to fulfill the user requirements [START_REF] Jean-Baptiste | Design process enabling adaptation in pervasive heterogeneous contexts[END_REF], as the capability of users, their acceptability, as well as target platforms capabilities of deployment environment and used devices configuration.

As the AAL systems considered as pervasive software systems [START_REF] Virone | Toward Information Systems for Ambient Assisted Living[END_REF], a number of non-functional requirements need to be considered in any system. Such nonfunctional requirements [START_REF] Schneider | Runtime Models for Self-Adaptation in the Ambient Assisted Living Domain[END_REF] are adaptability, interoperability, availability, distributed access points, maintainability, price, acceptability, etc... Some of these requirements are specific to home automation support systems [START_REF] Allegre | Flot de conception dirigé par les modèles pour la commande et la supervision de systèmes domotiques d'assistance[END_REF], which can summarized by the following:

 Adaptability: In definition, the ease with which a system or component can be modified for use in applications or environments other than those for which it was specifically designed [8]. As a crucial requirement for AAL systems, home automation services must address the specific needs of users, closely related to their disability, but also the configuration of their living space. In [START_REF] Lamprinakos | An Integrated Architecture for Remote Healthcare Monitoring[END_REF], different requirements of the various users, according to their capabilities and disabilities, in addition to the evolution of these requirements must be considered, as well as the evolution of the living space. This includes the ability of adapting the services dynamically without user intervention.  Interoperability: According [8], interoperability is the ability of two or more systems or components to exchange information and to use the information that has been exchanged. We must address the heterogeneity of technologies and communication protocols found in a home, as well as those who are to be integrated. Smart home environment includes various types of heterogeneous systems and services [10]. These heterogeneous systems are belonging to different middlewares [START_REF] Miori | An Open Standard Solution for Domotic Interoperability[END_REF], totally isolated from each other, and running with different technologies. The heterogeneity of systems considered as an essential challenge for the integration of all devices according to a standard mechanism that makes the heterogeneous systems interoperable and "speak the same language" apart from the used technology [START_REF] Miori | An Open Standard Solution for Domotic Interoperability[END_REF].  Reconfiguration: Reconfiguration is defined in [START_REF] Lankari | Multi-Level Reconfiguration in the DANAH Assistive System[END_REF] as "reconfiguration is a process to perform changes to the system to ensure correct suitability to the current context. Changes can be made to the software, the hardware, or to both, and are triggered due to either objective changes (adaptively), or to service failures (faulttolerance)". The availability in case of failure is an essential feature that must be taken into account to ensure the delivery of a service [START_REF] Lankari | Service Reconfiguration in the DANAH Assistive System[END_REF]. In other words, it is the ability to overcome the failure of service implementation through the definition of different scenarios during the design time. Reconfiguration is performed using statically defined reconfiguration rules in resource descriptions [START_REF] Lankari | Multi-Level Reconfiguration in the DANAH Assistive System[END_REF], [START_REF] Lankari | Service Reconfiguration in the DANAH Assistive System[END_REF], or in a dynamic manner based on reconfiguration rules generated in execution time.  Distributed access points: In [START_REF] Queirós | Usability, accessibility and ambient-assisted living: a systematic literature review[END_REF], the degree to which a component, including devices, systems, resources or services, can be used by as many people as possible.

The services provided by the AAL system need to be accessible from different access points, in order to make all users (medical staff, the elderly, the relatives) participate in using the services according to their roles [START_REF] Jean-Baptiste | A design process enabling adaptation and customization of services for the elderly[END_REF].

What have been introduced in this section are some issues that are specific to the home automation assistance systems or AAL solutions, when other requirements are involved in the general acceptance of a home automation solution and related to the common approval of final users, which is efficient and effective towards elderly people needs, based on adding non-functional attributes to the ICT solution [START_REF] Sun | The Missing Ones: Key Ingredients towards Effective Ambient Assisted Living Systems[END_REF].

Overview Of AAL Systems

In recent years, the EU has funded different projects promoting independent living for elderly. As examples of these projects, the project funded by ICT Policy Support Programme under the Competitiveness and Innovation framework Programme (CIP) [START_REF] Perumal | Interoperability among Heterogeneous Systems in Smart Home Environment[END_REF] and the Seventh (FP7 -2007-2013) Framework Programmes for Research and Technological Development [19].

The Ambient Assisted Living Joint Program (AALJP) [20] is focused exactly on this topic. The solutions funded by this program are categorized, according to the afforded solutions, into six key groups as stated in [20].

In this paper, four systems have been chosen to be introduced and to be evaluated according to specified requirements. Choosing of those systems are based on the well documentation provided with each of them, in which the functionalities and the architecture of each system are described, in addition to the scientific papers and publications related to each system, in which the objective and the services they provide are illustrated in details. The four projects are briefly described in the following sub sections.

GiraffPlus

GiraffPlus (January 2012-December 2014) is one of many running projects that are financed by the CIP and the FP7 [START_REF] Coradeschi | GiraffPlus: Combining social interaction and long term monitoring for promoting independent living[END_REF]. This project addresses number of issues related to enhance the well-being of elderly people and extend their independency of living, by the early detection of possible health problems to decline them and providing services to assist those have deficiencies [START_REF] Cesta | Steps Toward End-to-End Personalized AAL Services[END_REF]. The main components of GiraffPlus system consists of a network of sensors that ubiquitously integrated in the home and categorized into physiological and environmental sensing devices. The collected data from these sensors are interpreted by an intelligent system which in turn prompts alarms or reminders for two kinds of users, the elderly users at home (primary users) and related caregivers and health professional (secondary users). The system consists also of telepresence robot, the Giraff robot, which is controlled over the internet by a remote user to move inside the home, in order to assist the elderly users to sustain their social contacts with other users. Giraff robot has an interface (similar to Skype) and equipped with communication facilities [START_REF] Cesta | Steps Toward End-to-End Personalized AAL Services[END_REF]. Further information about GiraffPlus can be obtained from [23].

InCASA

"Integrated Network for Completely Assisted Senior citizen's Autonomy (InCASA)" (April 2010 -September 2012) deals with citizen-centric technologies and public/ private services network, to help and protect independent elderly people, prolonging the time they can live well in their own home by increasing their autonomy and self-confidence [START_REF] Lamprinakos | An Integrated Architecture for Remote Healthcare Monitoring[END_REF], [START_REF] Prestileo | inCASA project -Smart telemonitoring[END_REF]. This project is also one of the projects that have funded by the CIP and the FP7.

The main objectives of InCASA project are to provide elderly people with solutions to monitor their health conditions when they are at their homes, to provide General Practitioners (GPs) and health professionals with technological facilities to remotely analyze and control elderlies' health conditions, and to ensure care continuity through the interaction between the elderly at home and his/her health professionals [START_REF] Lamprinakos | An Integrated Architecture for Remote Healthcare Monitoring[END_REF], [START_REF] Lioudakis | Introducing Privacy-Awareness in Remote Healthcare Monitoring[END_REF], [26]. In order to meet its objectives, InCASA architecture is organized into three main tiers which purpose at providing integrated solutions and services to control the environment and health conditions for the elderlies and give feedback and alerts to the users. The three tiers are illustrated in [START_REF] Lioudakis | Introducing Privacy-Awareness in Remote Healthcare Monitoring[END_REF].

eCAALYX

This project is one of many projects that has been developed and currently developed under the AALJP Programme. The AAL JP is "a funding activity that aims to create better condition of life for the older adults and to strengthen the industrial opportunities in Europe through the use of information and communication technology (ICT). It carries out its mandate through the funding of across-national projects (at least three countries involved) that involves small and medium enterprises (SME), research bodies and user's organizations (representing the older adults)" [START_REF] Boulos | Connectivity for Healthcare and Well-Being Management: Examples from Six European Projects[END_REF].

The project eCAALYX (Enhanced Complete Assisted Living Experiment) is a three-year project between 2009 and 2012. ECAALYX continued the advantages of the architecture and functionality that are developed by the project called CAALYX [START_REF] Boulos | Connectivity for Healthcare and Well-Being Management: Examples from Six European Projects[END_REF], [START_REF] Boulos | ECAALYX: Towards a Real-world Ambient Assisted Living Solution that Delivers in Non-technical Environments and Is Sustainable[END_REF], and aims to provide a solution in order to improve the well-being of elderly people at home and extend their independency for longer periods, by developing home and outdoors 24/7 health telemonitoring / telehealthcare services for older people, including those with multiple chronic conditions. The key objective of eCAALYX project is [START_REF] Boulos | Connectivity for Healthcare and Well-Being Management: Examples from Six European Projects[END_REF], [START_REF] Boulos | ECAALYX: Towards a Real-world Ambient Assisted Living Solution that Delivers in Non-technical Environments and Is Sustainable[END_REF] to monitor the health of elderly people and people with chronic conditions, in order to improve their quality of life by strength their autonomy and safety, by providing continuous health support for elderly persons that assists in prolonging the need for intervention from health professionals and avoiding the descent of health circumstance. The project objectives could be accomplished by providing an ICT solution that meets all users' expectations.

The proposed ICT solution is based on an architecture, which consists of three main interconnected subsystems which are Home Subsystem, Mobile Subsystem and Caretaker Subsystem. This architecture is figured out with more details in [START_REF] Boulos | ECAALYX: Towards a Real-world Ambient Assisted Living Solution that Delivers in Non-technical Environments and Is Sustainable[END_REF].

Danah

This project is one of seven projects that are emerged by the team MOCS (Methods, Tools for Circuits and Systems) in the Lab-STICC laboratory in France. This team participated for many years in the development of home automation projects aiming to assist dependent people. The researches area of these projects is particularly "pervasive systems to help the handicaps" [START_REF] Allegre | Flot de conception dirigé par les modèles pour la commande et la supervision de systèmes domotiques d'assistance[END_REF]. These projects are funded by the Bretagne region and the General Council of Morbihan.

The main objective of Danah project ( 2006) is to set out the different scientific issues from previous projects to improve the propositions that have been made [START_REF] Lankri | Architecture and Models of the DANAH Assistive System[END_REF]. The project proposed a middleware that integrates a process of multilevel reconfiguration, static and dynamic reconfiguration of home automation services, in addition to the topological reconfiguration of paths for the movement of an intelligent wheelchair. Danah middleware is based on client-server architecture (distributed system). Home automation terminals (Danah servers), are distributed in the environment [START_REF] Allegre | Flot de conception dirigé par les modèles pour la commande et la supervision de systèmes domotiques d'assistance[END_REF], [START_REF] Lankari | Multi-Level Reconfiguration in the DANAH Assistive System[END_REF]. A terminal can thus be connected to a home automation bus KNX-EIB [START_REF] Lankri | Services et Navigation pour Personnes Dépendantes en Environnements Domotiques[END_REF] to control equipments connected to it. Other terminals are responsible for monitoring equipment to local activation via infrared or Bluetooth such as multimedia equipment. The user, equipped with a PDA (Personal Digital Assistant) embedded in his wheelchair, has the opportunity to reach the services and methods published by these terminals.

Evaluation Of The Systems

Following the identification of AAL requirements in addition to the introduction of different AAL projects and knowing their architectures, this section, evaluate the previous projects from system requirements perspective; the four AAL solutions should be investigated to emphasize if they meet the general AAL requirements which have been mentioned in section [START_REF] Helal | The Engineering Handbook of Smart Technology for Aging, Disability and Independence[END_REF]. Those requirements again are: adaptability of services, interoperability of services, reconfiguration, and distributed access points.  GiraffPlus is configured to have an important feature that makes the system adaptive in a way allowing for adding and removing services easily and related sensors that provide these services. In addition, the system is configured to accept the adaptation [START_REF] Cesta | Steps Toward End-to-End Personalized AAL Services[END_REF]. The system architecture consists of number of integrated functionalities; one essential part of system architecture is "Data Visualization, Personalization and Interaction Service" which is responsible for creating useroriented service. In addition, the system meets the requirement of distributed access points, since it includes not only the users at home, but also their family members and caregivers who are able to connect and control Giraff robot, as well as have access through PCs to the information and activities of the elderly people. This also applied for the medical stuff that are also can access the system to obtain health measurements [START_REF] Coradeschi | GiraffPlus: Combining social interaction and long term monitoring for promoting independent living[END_REF]. GiraffPlus system architecture is designed by integrating a middleware infrastructure that hiding the heterogeneity of the computational resources used in the living space, since that the services provided by the system components are developed using different technologies and connecting with each other using different protocols.  InCASA system is developed using an architecture that allows for the main blocks of the system to communicate regardless the used protocols or the coding modules [START_REF] Prestileo | inCASA project -Smart telemonitoring[END_REF], which in turns undertake the heterogeneity of protocols, which are used in the Body Sensor Network and in the Home Sensor Network [START_REF] Lamprinakos | An Integrated Architecture for Remote Healthcare Monitoring[END_REF]. The functional architecture of InCASA are realized using four levels of communication at home, with service center and with external users such as relatives, caregivers and general practitioners, which give different users of the system the ability to use the system and interact with it from different locations.  eCAALYX home healthcare monitoring approach is performing the provided services depending on a system architecture that permits customization of the services, which makes these services adaptive to each user needs including the changing condition of the users at home [START_REF] Boulos | ECAALYX: Towards a Real-world Ambient Assisted Living Solution that Delivers in Non-technical Environments and Is Sustainable[END_REF], by reusing the Telecom remote management infrastructure as a unifying layer between different low-level sensor communication protocols and health communication standards. The interoperability between different system components is also underlined, since eCAALYX eHealth service interoperability approach "builds on Continua Version One standard and the Broadband Forum TR-069 CWMP specification" [START_REF] Boulos | ECAALYX: Towards a Real-world Ambient Assisted Living Solution that Delivers in Non-technical Environments and Is Sustainable[END_REF]. "Continua" is a defined standard that aim to develop ICT based healthcare systems following interoperability guidelines [START_REF] Carroll | Continua: An Interoperable Personal Healthcare Ecosystem[END_REF].

 Danah project is considered the reconfiguration of services in case of failure by defining a set of reconfiguration scenarios in the resource description. The developed middleware in the system, allows to deploy Danah in heterogeneous living space, regardless of the communication technology and used technologies, since the system uses different communication protocols to communicate clients with servers, such as KNX/EIB, X10, infrared, Bluetooth, and WiFi [START_REF] Lankri | Services et Navigation pour Personnes Dépendantes en Environnements Domotiques[END_REF]. Table [1] summarizes the general AAL systems' requirements and how they are met by the four systems.

Conclusion

An Ambient Assisted Living system is characterized by its functional and nonfunctional properties that it contains to meet its users expectations and needs. Increasing the efficiency and effectiveness of a system is achieved when it has as features as possible to reach it objectives. The main contribution of this paper is to evaluate number of Ambient Assisted Living Systems in order to characterize the main features that these systems have included. This evaluation based on identified requirements. By studying the different AAL systems according to the stated requirements, it is outlined that these systems meet the requirements partially. Thus, the attempt is to propose a system that meets all requirements so that it can be govern that the system meets all users' expectations. From this study, it is also stated that reconfiguration as an essential requirements is not considered systemically in most AAL systems, even though reconfiguration and failure tolerance in case of error occurrence, is considered a crucial requirement for distributes systems, especially those systems that deals with health conditions and assistance such as AAL systems.

Adaptability

Interoperability Reconfiguration Distributed Access Points


A Thépaut

M T Segarra

C Lohr

P M Chapon

Adaptation and customization of services for the elderly

Keywords:

Information and communication technologies may be used to improve the quality of life of elderly people. However, the use of such techniques may be challenging for the elderly. In this paper, we present our experience on the deployment and experimentation of ICT technologies for older people that lead us to focus our work on adaptation.

Methods

Since 2001, the SID research group of Telecom Bretagne works on proposing a service-oriented platform intended to help people with disabilities to improve their quality of life. The platform is composed of a set of servers and interaction devices to access available services. These devices have been advocated by the end users themselves and concern a TV set and its remote control device. The platform [START_REF]Companymages Project Home Page[END_REF] was intended to be deployed and evaluated by seniors in a retirement home in the district of Bellevue in Brest by June 2009. The district of Bellevue was chosen due to strong relationships between the SID team and the City Hall, associations, and social services. In order to identify services to be developed, a team of sociologists interviewed the technical staff, elderly people, caregivers of the retirement home, and local authorities during six months. Four types of services have been identified: (i) communication with the social network of the elderly; (ii) infotainment services, and in particular accessing local news; (iii) management of daily activities; (iv) access to individual games or multi-players.

Results and discussion

Early returns showed the difficulties experienced by some seniors to access services. For example, seniors who suffer from muscular problems have great difficulties in using the first proposed remote control device which was not stable enough. The visually impaired people cannot read text on the television. So a text to speech system was added to the platform. Nevertheless, the adaptation of services for each person need seems impossible in the context of a deployment on a larger scale. Therefore, we are currently working in a new project, SIGAAL, (Special Interest Group on Ambient Assisted Living), supported by French State ("Direction Générale des Entreprises"). The project brings together 11 partners and will focus on adaptation of services. It allows for low cost devices helping on maintaining or even strengthen social ties and detecting incipient vulnerabilities of older people at home. In this sense, work is underway on changing size and font of characters in real time to address each individual reader and to adapt to her current capabilities. We are also working on an expressive text to speech system that is able to vocalize text using the voice of the person with whom one exchange messages. Finally, as adapting services depends on elderly capabilities as well as the execution environment where services execute, developing each configuration is not a satisfying solution. Moreover, changing from one configuration to another may be challenging depending on the changes to be performed. Therefore, we intend to propose a methodology for automating the development of adaptation mechanisms based on the work proposed by [START_REF] Kaboré | Implementing a Data Distribution Variant with a Metamodel, Some Models and a Transformation[END_REF] and [START_REF] Phung Khac | Model-Driven Development of Component-based Adaptive Distributed Applications[END_REF].


Ali Sajjad

Osman Musthaq
email: sajjad.musthaq@telecom-bretagne.eu

Christophe Salem
email: christophe.lohr@telecom-bretagne.eu

Annie Lohr

Gravey

Distributed Call Admission Control in SIP Based Multimedia Communication

Keywords: Distributed Call Admission Control, SIP Priority Header, QoS (Quality of Service), Competitive Cluster

The Session Initiation Protocol (SIP) is a text based signaling protocol, which has been adopted in Next Generation Network (NGN) for controlling multimedia communications. The present paper addresses issues related to Call Admission Control (CAC) for a private network (A competitive cluster where proposed architecture blends various devices/components from several partners; Call Server (CS) from one partner and Session Border Controller (SBC) from another in the platform) accessing the rest of the world through various links. The standard SIP messages are used to share and distribute required information between different devices in the network. In this architecture, an efficient CAC function should take account of many factors, including user profile, call type and the state of the available access links. We propose to distribute the CAC function between the CS and SBC; the CS handles issues related to user profile and the SBC handles issues related to resource availability. The collaboration between CS and SBC is made possible by using the "SIP Priority header" to share and exchange information during Call Setup. This mechanism helps in isolating the service, control and transfer planes from each other.

I. INTRODUCTION

The emergence of multimedia services in IP network makes Quality of Service (QoS) management an unavoidable task. Call Admission Control (CAC) is one of the important mechanisms to provision the required QoS. The role of CAC is to determine whether or not a new call can be admitted. A large number of algorithms have been proposed in the literature. Classification, evaluation and performance analysis of some of the proposed algorithms have been done comprehensively in [START_REF] Knightly | Admission control for statistical qos: theory and practice[END_REF]. An interesting scalable CAC algorithm has been presented in [START_REF] Ali | A scalable call admission control algorithm[END_REF]. A new dimension of dynamic pricing with CAC has been added in [3]. Distributed intelligent CAC for wideband multi-service CDMA system has been introduced in [START_REF] Zhang | Distributed intelligent call admission control[END_REF]. Networks require an effective resource management to provide required QoS, not only at connection setup as it has been implemented in most of existing CAC mechanisms, but also during the lifetime of the connection. CAC is regarded as an adequate tool to accomplish the required task in an efficient way.

Service provider has to take care of QoS requirements of the ongoing flows, before accepting a new request that may degrade the performance of ongoing flows. Several CAC schemes have been proposed focussing on call and packet level performances [START_REF] Nan | Admission control algorithm for real-time services in packet-switched ofdm wireless networks -norm[END_REF], [START_REF] Yang | Optimizing admission control for multiservice wireless networks with bandwidth asymmetry between uplink and downlink[END_REF]. Conventional CAC schemes take into account the inbound traffic load, outbound traffic load, QoS of the links, user profile, thresholds defined to limit the number of voice/video calls and Central Processing Unit (CPU) load. Network topology and resource status are essential for CAC mechanism. Dynamic/real-time awareness of the network topology and resources is key to ensure policy based dynamic CAC. Admission control in the present paper involves checking authorization based on policy rules computed while taking into account user profiles, Service Level Agreements (SLA), operator specific policy rules, business objectives and service info. Proposed CAC mechanism is distributed into profile and resource based phenomenon, according to the functionality and location of the service management devices. In our architecture, the policy based CAC mechanism has been splitted and performed at distinct locations (Call Server (CS) and Session Border Controller (SBC)) taking into account already admitted flows. Certain information elements need to be shared and exchanged between CS and SBC to achieve the goal of CAC distribution. There is no such algorithm/scheme and protocol at hands to be adopted for information exchange and sharing while distributing the CAC. Moreover, the utilization of a new protocol may complicate the problem, and requires more computation with rise in call/connection setup time. One of the motivations is to accomplish the CAC distribution mechanism within the session signaling flow and/or its initiation.

The remainder of this paper is organized as follows: In section II, we describe the proposed architecture along with its brief layered comparison with IMS. Section III explains the call admission control and its distribution along with use cases for incoming and outgoing calls. In section IV, we discuss the advantages of proposed architecture, CAC distribution advantages and disadvantages and finally some concluding remarks have been given.

II. PROPOSED ARCHITECTURE

SIP [START_REF] Rosenberg | SIP: Session Initiation Protocol[END_REF] (The main signalling protocol in the proposed architecture) is widely used in IP based communication and is adopted in TISPAN and Next Generation Network (NGN)/IP Multimedia Subsystem (IMS). SIP is an ASCII based application layer protocol used to set up and tear down voice, video and data sessions. It is an Internet-centric protocol that establishes, maintains, modifies and terminates sessions. Despite the Network Address Translation (NAT) and firewall traversal issues, SIP has been admitted as the promising candidate for NGN and is being incorporated in the current and future multimedia services. QoS-centered proposed architecture provides linkage between private network (Where companies offering versatile services are linked to the rest of the world via different accesses) and the public network (The Internet). Policy Based Network Management (PBNM) paradigm in the architecture envisaged an extended IETF framework [START_REF] Westerinen | Terminology for Policy-Based Management[END_REF]. This architecture (See figure 1) is proposed in the Companym@ges [9] project (A project that stems from Competitivity Cluster "Images and Network") which proposes a platform where companies are linked to the rest of the world via different network accesses offering data and multimedia services. The work presented in this paper relates to the sub-project for traffic management issues at the border of the company's network. Components of this platform are provided by partners: SIP Call Server (CS), Session Border Controller (SBC), and Policy Server (PS)) constituting the control plane in the proposed architecture (figure 1) are/will be developed by Alcatel-Lucent, Comverse and TELECOM Bretagne respectively. It is thus interesting to use the standardized SIP messages to distribute the CAC procedure. The proposed CAC mechanism has no impact on other priority header fields utilization/information.

Application Servers (AS); constituting the service plane and CS, SBC, PS; constituting the control plane are the main building blocks of the proposed architecture. CS is an important component of IP based PBX/Softswitch. It may also support proxy, registrar, redirect and location services. Most of the CS solutions are proprietary and support wide range of services. CS here provide registration, user profile management, service control and user profile CAC functionality.

SBC is another significant module of the proposed architecture. It is a session aware device. The primary functionality of the SBC is Network Address and Port Address Translations (NAT/PAT) and firewall traversal. The term SBC is not specific since its functionalities are not yet standardized or defined anywhere [START_REF] Hautakorpi | Requirements from SIP (Session Initiation Protocol) Session Border Control Deployments[END_REF]. SBC provides a variety of functions to enable or enhance session based multimedia services (e.g. VoIP). The key functions of SBC are: Perimeter defence (access control, topology hiding, DOS prevention and detection), functionality not supported at the end points (protocol interwork, media repair) and network management (traffic monitoring, shaping and QoS). Some of these functions may also get integrated into other SIP elements like 3GPP P-CSCF, 3GPP I-CSCF etc. SBC can handle both signalling and media depending upon its functionality and deployment. In our case, we assume that SBC also embeds: a SIP/SDP (Session Description Protocol [START_REF] Handley | SDP: Session Description Protocol[END_REF]) analyzer, a communicator function (used for policy and information exchange between PS and SBC), network QoS monitoring and policy enforcement module. It can also act as a Local Policy Decision Point (LPDP) to support provisioning mode policy enforcement. The modular inter-communication within the SBC and with other components of the platform is shown in figure 2. PS is the core of our proposed architecture. An abstract modular diagram of PS is presented in figure 2. Policy based management system is emerging as the promising technology to address the challenging tasks in the converged NGN [START_REF] Shepard | Policy-based networks: hype and hope[END_REF], [START_REF] Flegkas | On policy-based extensible hierarchical network management in QoS-enabled IP networks[END_REF]. IETF policy framework terminology and concepts has been adopted and extended to formulate an enhanced framework capable of taking into account high variability and dynamicity. policy framework keeping in view integrity and compatibility. Conventional policy based systems do not allow dynamic control, management and extensibility. Although some policy based systems have been proposed for managing telecommunication and enterprise network services [START_REF] Lymberopoulos | An adaptive policy based management framework for differentiated services networks[END_REF], [START_REF] Verma | Policy Based SLA Management in Enterprise Networks[END_REF], but those systems were specifically designed for a certain set of services and environments with limited dynamicity. We have tried to provide a policy system which support converged network services with dynamicity emphasizing on access network optimization. PS is an intelligent and key player in our framework. It has to obey the Service Level Agreements (SLA) and reciprocal agreements. The business objectives of the enterprize must be fulfilled while the users and applications should get assured QoS. We have also addressed the access optimization by taking into account the information narrated along with routing rules and configurations entered by the administrator. In order to provide required QoS for multimedia services, the policy server provides a decision for every request by considering static information and dynamic information (e.g. time of day, context of the external links, Statistical analysis of QoS information or Call Details Records (CDRs), etc.).

The policy system supports multi-service and multi-vendor environment with high variability while isolating the service, control and access planes. The decoupling of three planes leads to distributed CAC functionality. The policy computation takes SLAs, business objectives, routing rules, services information, QoS of the accesses and profiles into account. The SNMP [START_REF] Harrington | An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks[END_REF] flows presented in figure 1 are used by the policy server to gauge the QoS of the external links by performing statistical analysis on captured metrics(delay, packet loss etc). Further description of the PS and its behavior is outside the scope of the present document. The reader is refereed to [START_REF] Mushtaq | Policy-based QoS Management for Multimedia Communication[END_REF] for detailed PS framework, functionality and behavior alongside the information required for dynamic policy control and management. In this paper, we have focussed on policy sensitive CAC issues, assuming that the PS provides decisions regarding call acceptance/rejection. The profile and resource based CAC policies might be exemplified with some simple policies as follows

• If the user profile belongs to silver class and the requested communication type is video, then refuse the request immediately.

• Give priority to voice calls.

• Preempt the loaded link-A (marked with exceptional good QoS) for incoming call from some specific profile. • Deny all video calls if occupied bandwidth is above predefined threshold. • If the load is below a predefined threshold on an access then despite refusing the request, route sesion/call to consume the dedicated Best Effort bandwidth. • While routing a session/call, look first for the best QoS link for a certain family of profiles then search/find the cheapest access.

A. IP Multimedia Subsystem (IMS) and the proposed architecture

An NGN is a packet based network able to provide telecommunication services and make use of multiple broadband, QoS enabled transport technologies. In NGN, service related functions are independent from underlying transport related technologies. IMS is a subsystem providing call processing and a variety of multimedia services over an IP based packet switching domain. IMS framework was originally designed for charging and mobility management in wireless environment.

Later on it has evolved for wired networks along with new wireless standards (CDMA 2000). Telecoms & Intenet converged Services & Protocol for Advanced Network (TISPAN) is responsible for all aspects (Service, architectural, protocol, QoS, security, mobility within wireless and wireline aspects) of standardization for present and future converged networks including NGN. 3GPP IMS has been extended in the TISPAN NGN [START_REF] Tispa | ES 282 007 IP Multimedia Subsystem (IMS); Functional architecture NGN IMS Architecture[END_REF]. Despite fast-release pattern IMS/NGN is still evolving. Policy control function and Flow Based Charging (FBC) are combined to form Policy and Charging Control (PCC) function in IMS 7. Additionally merging of Gq and Rx as Rx+ and integration of Go and Gx as Gx+ are latest evolutions in the current IMS release 7 [START_REF][END_REF]. Due to aforementioned competitive nature of Companym@ges project, we need fine granularity at resource and profile level especially handling the private-public border traffic management issues along with external links optimization. IMS might not provide such fine tuned granularity at the private-public border. Adaptation effort may require lot of efforts and it might generate extra signalling traffic. Conventional SBC in IMS may offer packet classification and forwarding to a given link according to IntServ/DiffServ [START_REF] Wroclawski | The Use of RSVP with IETF Integrated Services[END_REF], [START_REF] Nichols | Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers[END_REF] schemes. But we have introduced access prioritization and proposed an upper level(Session/Call level) classification framework. The focuss of present work is distributing the policy sensitive CAC mechanism irrespective of the components/devices from diverse vendors/partners. We therefore adopt high level layered approach for IMS and proposed architecture comparison as shown in figure 3. QoS oriented policy controlled framework emphasizing on SIP based multimedia communication is presented. The decoupling of service, control and access planes is one of the main features of the proposed architecture. This decoupling facilitates the distributed CAC mechanism despite interfaces/devices from diverse partners/vendors. A fundamental tenet is the policy control at each plane. Coordinated information sharing and retrieval among those planes ensures dynamic policy sensitive CAC distribution at different locations. This phenomenon stipulates reliable and efficient resource management and control.

IMS

III. CALL ADMISSION CONTROL

A. Splitting the CAC procedure Call Admission Control (CAC) is a mechanism used in networks to restrict access, in order to provide QoS for real time applications. CAC is used to limit the number of connections in the network and in some cases it works jointly with the bandwidth allocation and QoS routing [START_REF] Ezaki | A new voip call admission control scheme with use of alternate routing for low call loss probability[END_REF]. It allocates available resources among the outgoing and the incoming connections, for maintaining the QoS performances of both types of connections at the required level. Network accepts or denies data flow on the basis of decision of CAC scheme. Decision (accept/deny) is based on predefined criterion which in turn depends on network environmental conditions in coordination with: rules, business objectives and administrative configurations of the platform. This decision has considerable influence on QoS parameters, which makes CAC an essential tool to guarantee various QoS parameters. Distributing the CAC mechanism on physical, data and network layer have been studied in [START_REF] Nan | Integrated Cross-Layer Design of Utility-Based Connection Admission Control in Packet-switched OFDM Wireless Networks[END_REF]- [START_REF] Oulai | End-to-End Packet Loss Constrained Routing and Admission Control for MPLS Networks[END_REF]. Distributed connection admission control in wireless network has been addressed in [START_REF] Safwat | Distributed Connection Admission Control and Dynamic Channel Allocation in Ad hoc-Cellular Networks[END_REF].

PBNM and CAC are strongly correlated as they share the same framework and go hands in hands. In our architecture, we propose to distribute the policy sensitive CAC into user profile and resources availability. The SBC sitting at the edge, as an access point between private and public networks, can handle availability, cost and quality of the accesses, so resource based CAC should be performed at the network border. The CS on the other hand have the latest knowledge of registered users, services, profile related AAA (Authentication, Authorization and Accounting) information. Therefore, it seems quite obvious and suitable to perform profile based CAC at call server in the proposed architecture (shown in figure 1). Another dimension of splitting the CAC among SBC and CS is the distribution of intensive computational complexity.

In the architecture, we split the CAC into user and resource based admission control mechanism. In our framework, admission is performed at distinct locations (CS and SBC). CS in the global architecture of figure 1 embeds both the registrar and proxy functionality. SBC sitting at the border is behaving as a SIP proxy along with its functionalities described in section II. SBC is able to route the calls to different accesses according to the routing policies computed from the rules (Business Objectives, SLAs, Routing Rules etc) entered by the administrator of the platform through management console. Moreover, policy server also takes into account QoS parameters of access router interfaces (using SNMP), bandwidth, loss ratio, CDR (Call Details Records) details of previous call, etc while computing new set of policies.

B. Communication between CS and SBC

CAC in an enterprise is outside the scope of SIP at the moment except if an outbound proxy is used for outgoing calls, that proxy may control the firewall and thus restrict outgoing calls. The integration of QoS admission control with call signaling is presented in [START_REF] Marshall | Private Session Initiation Protocol (SIP) Extensions for Media Authorization[END_REF]. But it violates general Internet principles, which separate data transport from applications. Thus, the solution described in this Request for Comments (RFC) document is not applicable to the Internet at large.

In order to illustrate the basic problem, consider the following situation in which Bob's SIP User Agent (UA) is registered on the CS and it initiates a call to Alice by sending an INVITE to the proxy server at CS (figure 4). SIP proxy at CS can identify the profile (user type) of the call sent (received) to (from) a given UA, by querying the profile database. The SBC can identify the communication type (audio, video, etc.) by analyzing the SDP [START_REF] Handley | SDP: Session Description Protocol[END_REF] payload of INVITE message. Therefore, the call server knows the profile type, while the SBC on the other hand, have the communication type information. In fact, the call server does not analyze the message payload and does not have any idea about the communication type while the SBC does not know the user type. Therefore, an information exchange and sharing is indispensable for policy base call routing at SBC.

One of the solution to this problem is that SBC accesses the profile database at CS and caches/mirrors the information within a duplicated database at SBC. This solution does not sounds efficient because the call server also accesses profile database frequently to filter incoming and outgoing calls. Hence the system has to access the profile base twice for each call, which is neither efficient nor elegant.

Our preference is the following: proxy server within the CS marks the INVITE with specific field that identifies the user type. 'Resource-Priority' and 'Accept-Resource-Priority' are defined according to the semantics in [START_REF] Schulzrinne | Communications Resource Priority for the Session Initiation Protocol (SIP)[END_REF]. It is intended to describe a structure for fields inserted in the header of INVITE message. The fields are used to communicate a priority level for accessing the resources. The structure of the priority field used in our implementation is name.number. The name identifies the resource, and the number identifies the priority level. We could define a name (e.g. company) and different priority levels corresponding to the different user types (e.g. boss, administrator, trainee student, etc.). These header fields are used to transport the user priority which is taken into account when a policy decision must be taken. The 'Resource-Priority' field will be used in INVITE messages while the 'Accept-Resource-Priority' field will be used in 200 OK answers.

C. Handling incoming and outgoing calls

The user type is set up and stored into the users profile database at CS. The CS looks at the user profile database to accept or reject the call. If accepted, it add a proprietary SIP header to carry the user type info. The proprietary SIP header will be removed by the SBC once it got the user type. Fig. 6. Incoming Call Flow.

The proposed system's architectural, functional and specification design phase has been completed and at present it is in the initial development phase.

IV. CONCLUSION

We have proposed a novel QoS-centered architecture in multiservice packet network for PBNM addressing the SIP based communication while emphasizing on admission control and resource management. Twin drivers of the CAC distribution mechanism (CS and SBC) share and exchange information using standardized SIP messages. Due the competitivity nature of the proposed architecture we compared it with IMS on layered basis. Our proposed architecture combines the granularity of Integrated Services (IntServ) and the scalability of Differentiated Services (DiffServ) with additional functions (e.g. Distributed CAC, layer 5 call routing, addition of profile groups, etc.). Policy based management within the enterprise is being done on per call basis (IntServ), the packets on the other hand are handled on the accesses on per class basis (DiffServ). The service, control and network planes (figure 1) has been decoupled, except some control and transfer plane functions overlap. This decoupling leads to the distribution of complex CAC functionality between CS and PS. Addition of new services without hardware/software upgrade and interruption, automatic discovery of access network failure (topology change) and policy based control at service, user and network level are the key advantages. CAC has been distributed and handled inside the session initiation and/or signaling. Policy enforcement becomes flexible and scalable and its complexity is reduced. The SIP header fields added inside the enterprise during CAC operation are removed by the SBC (from 200 OK response) at the edge before forwarding the message to the public domain so that this information might not be exploited in the routers inside the public network.

The advantage of the proposed architecture is three fold. First, the service, control and network planes are kept isolated. Second, the change in topology likely due to an external link failure, recovery of a broken link, addition of a new link will be sensed and accommodated without interruption. Finally the policy based CAC has been distributed between the edge device (SBC) and the SIP CS. Computation intensive policy based CAC mechanism here is implemented in a distributed fashion splitting it into profile and resource based CAC. This is not a standardized methodology to achieve the goal but it is an efficient way of doing the job from our view point. Division of complex and resource (CPU, Memory etc) hungry functionality, reduction of policy enforcement complexity, isolation of service, control and network planes, affinity between the calls and external links, affinity between the calls and user profile are the key advantages of CAC distribution. Call processing twice at two distinct locations(CS and SBC) may be regarded as a disadvantage. The call setup time as a result may rise. Two additional fields (Resource-Priority and Accept-Resource-Priority) have been introduced in SIP header, for sharing and exchanging information for distributed CAC phenomenon.

Fig. 1 .

 1 Fig. 1. Proposed Architecture.

  Fig. 2. PS and SBC modules and the modules inter-communication

Fig. 3 .

 3 Fig. 3. IMS and Proposed Architecture Layered Comparison

Fig. 4 .

 4 Fig. 4. Abstract Architecture.

TABLE III ADDITION

 III communication type is computed according to media & codec used by the user. Such information is described by the SDP message between user agents. The user type information is extracted from the Resource-Priority and Accept-Resource-Priority header fields, while the communication type is computed by the SIP/SDP analyzer at SBC (SDP offer/answer messages). This information is bundled into a pair and is compared with the switching table shown in table I (policy based QoS routing), computed from policy database. For incoming calls (INVITE from public to the private network), the Accept-Resource-Priority header must be added to the 200 OK message as shown in table III. OF Accept-Resource-Priority IN SIP INVITE FOR INCOMING CALL.Policy enforcement in case of incoming call is applied in 200 OK response, as shown in figure6.

	Bob (UA)	CS	SBC	Alice (UA)
	INVITE (Cseq = 1)
		INVITE (Ressource-Priority:
		company_xyz.2)
	Policy enforcement 100 Trying 180 Ringing 200 OK SBC does not know the user profiles. SBC gets the user associated priority through the «Resource-Priority» INVITE 100 Trying 100 Trying 180 Ringing 180 Ringing 200 OK 200 OK header of INVITE Fig. 5. Outgoing Call Flow. Call Type Access (User Type-1,Communication Type-A) 1 (User Type-1,Communication Type-B) 3 (User Type-3,Communication Type-C) 2 (User Type-2,Communication Type-A) 1 TABLE I SWITCHING TABLE FOR ROUTING 1) Outgoing Call: For outgoing calls (i.e. for INVITE sent from platform to outside), the 'Resource-Priority' header must be added to the INVITE message as shown in table II. For an INVITE sip:bob@xyz.com SIP/2.0 Via: SIP/2.0/UDP 192.168.1.156:5060;branch=xxxx Session-Expires: 86400 From: "Alice" <sip:alice@xyz.com:5060>;tag=xxxxx To: <sip:bob@xyz.com:5060>;tag=xxxx Call-Id: XXXXXxxxxx CSeq: 1 INVITE Resource-Priority: compagny xyz.2 Contact: "Alice" <sip:Alice@xyz.com:5060>;tag=xxxx Max-Forward: 70 Allow: ACK,BYE,CANCEL,INVITE,NOTIFY, . . . User-Agent: useragent name Content-Type: application/sdp Content-Length: xxx TABLE II ADDITION OF Resource-Priority IN SIP INVITE FOR OUTGOING CALL. outgoing call, policy enforcement will be done on the INVITE response (200 OK). We should trigger on SDP offer/answer as shown in figure 5. 2) Incoming Call: SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.1.156:5060;branch=xxxx Session-Expires: 86400 From: "Alice" <sip:Alice@xyz.com:5060>;tag=xxxx To: <sip:bob@xyz.com:5060>;tag=xxxxx Call-Id: XXXXXxxxx CSeq: 1 INVITE Accept-Resource-Priority: company xyz.1 Contact: "Bob" <sip:bob@xyz.com:5060>;tag=xxxx Allow: ACK,BYE,CANCEL,INVITE,NOTIFY, . . . Content-Type: application/sdp Content-Length: xxx Policy SBC CS Bob (UA) Alice (UA) INVITE INVITE (Cseq = 1) INVITE 180 Ringing 180 Ringing 180 Ringing 200 OK 200 OK (Accept-Ressource-Priority: company_xyz.1) record-route and new SDP for enforcement SBC does not know the user profiles. SBC gets the user associated priority through the «Accept-resource-priority» header of 200OK Ack Ack enforcement 200 OK

A

ACKNOWLEDGMENTS

This work has been partially funded by the DGE (Direction Générale des Entreprises/Ministère des Finances et de l'Industrie) through the Companym@ges project. The authors would like to give many thanks to Antoine Gatineau from Comverse and to Yves Blanchard from Alcatel Lucent for their support and guidance.