The project will be carried out in the following three main stages:  
1. Determination of interest and relevant target scenarios. This takes into account:
• Communications environment, i.e. macrocell, microcell, indoor, etc., and user mobility
• Technologies deployed (GSM, GPRS, EDGE, UMTS, WLAN), their corresponding capabilities and functionalities, as well as their corresponding network architectures and entities
• Service mix and service load (conversational, interactive, streaming, etc.)
This activity is carried out in WP2  

2. Development of RRM and QoS management algorithms, with evaluation through simulation. Focus will be placed on finding commonalities among the different scenarios considered, rather than trying to optimise algorithms and algorithmic parameters for a specific scenario. Thus, the goals of EVEREST extend the mere analysis of different scenarios and will target the definition of generic RRM criteria, facilitating their applicability in scenarios differing from those studied in detail within the project.
This activity is carried out in WP3  

3. Validation and demonstration of the proposed algorithms for the defined scenarios by means of a real time testbed supporting IP-based mobile multimedia applications with end-to-end QoS capabilities. To support this latter service, the IP CN has to be configured in the following way: a mobility management has to be installed, and the QoS framework based on Diffserv, including its control plane, has to be configured. Then, the interactions of the BB with the radio resource entities will be considered.
This activity is carried out in WP4  

These main research topics in EVEREST will be addressed within a proposed end-to-end QoS management framework aligned as much as possible with the QoS architecture envisaged in 3GPP Release 5 and 6 and other relevant IETF proposals. In this sense, it is assumed within the project that any end-to-end QoS architecture for converged 3G mobile – wired IP networks should be compliant with 3GPP UMTS QoS general framework (ref. 3GPP TS 23.107, TS 23.207).

A key goal of the QoS architecture taken as a reference within EVEREST should be the support of end-to-end paths in IP multi-network over various access technologies. It is expected that end-to-end scenarios in future wireless systems can encompass several L2 hops and multiple IP networks. End-to-end QoS guarantees need to be spread along all domains involved in the communication path. QoS handling in each domain can follow different QoS models as the ones outlined for DiffServ domains and UMTS networks. This concept has been addressed from different perspectives and different approaches exist although no one offers a complete solution according to EVEREST's goals.  

A first approach of this multi-domain scenario, called ABC, has been proposed [1]. Within the ABC vision, and end-to-end path is established though several different IP-based domains according to the following key issues:

• QoS requirements are user-driven and are instantiated by means of wireless hints (Information Elements that are QoS-mechanism-agnostic and access-technology-agnostic).
• Each involved domain contains a IP QoS aware element, named IP QoS Controller in the proposal, with is equivalent to the IP BS Manager element introduced in UMTS.
• There is a need for some QoS information distribution mechanism among the QoS Controllers in each domain.
• Each network domain makes a local decision to translate distributed QoS parameters into specific domain QoS provision.  

However, the ABC proposal has some open issues that are considered relevant within EVEREST and should be taken into account. Among these open issues we can remark:

• How partitioning of QoS is carried out among the involved domains.
• How other aspects than those related to resource management can be considered in QoS Management decisions.
 

Another end-to-end approach, which proposes a policy-based QoS management architecture applied to a multi-domain scenario, was been also envisaged [2]. In this work, QoS Management in each domain is done according to a set of policy rules that are negotiated and maintained in a consistent way by all the involved domains that can be traversed when establishing a user session.  

According to both approaches, in EVEREST, it is proposed to extend the ABC end-to-end architecture in order to support a service-based policy management as depicted in Figure 1

According to previous end-to-end and to the UMTS QoS architectures, Figure 2 shows a proposed architecture for QoS handling in a Heterogeneous Radio Access Network with CRRM capabilities. As shown in the figure, different RANs are envisaged to offer access to the same Core Network (tight coupling approach) and CRRM functions are used to manage radio resources optimally. The proposed architecture is more aligned with the vision of UMTS Release 6 and envisages the possibility of using a Diffserv-enabled IP network as Core Network. Among the key aspects of the proposed architecture we can remark:

• SGSN control functions are separated from its routing functions. This approach is intended to introduce native IP transport down to the RNC and its equivalents.
• UMTS core network is a Diffserv network and mobility management solutions other than GTP are used. QoS management in CN might be addressed according to the bandwidth broker concepts [3].
• Functions associated to the so-called Wireless QoS Broker in the Figure include the ones envisaged in the Radio Access Bearer Manager considered in UMTS (see Figure) plus all the additional functions derived from the handling of different RAN simultaneously (CRRM co-operation).
• Policy-based framework mechanism to manage end-to-end QoS policies. Besides, within the heterogeneous access networks this framework may be extended up to RNCs and its equivalents.
• As detailed below, the proposed architecture is flexible enough to cope with different approaches about common RRM that are going to be addressed within the project.

Figure 2. EVEREST proposal for QoS Architecture in a heterogeneous radio access network

Focusing on CRRM issues, two main approaches are envisaged to support CRRM in UTRAN and GERAN: integrated CRRM and loose RRM [ (TR 25.881, TR 25.891 ):

• Loose architectures are based in a CRRM server linked by open interfaces to the RNC (UMTS) and BSC (GERAN). CRRM Server establishes CRRM policies and each RAT executes RRM algorithms according the CRRM server policies (e.g. when a determined load is overcome). Within this approach, CRRM may contain updated and ordered information from the different RATs. Figure 3 illustrates the CRRM architecture.

• On the other hand, integrated CRRM, also referred to as tight CRRM, incorporates CRRM functions into the existent UTRAN nodes. Hence, proprietary Interfaces are needed and non radio dependent messages get trough indistinctly in each RAT air Interface. Figure 4 illustrates the integrated CRRM architecture.

Notice that, in principle, the two architectures should impact only the performances of CRRM algorithms without introduce any other considerable limitations.

Finally, WLAN access will be also taken into consideration within EVEREST since it is believed it will have and important part to play in the future of 3G evolution. Focusing on CRRM aspects, it should be noticed that nowadays there is still no standard entity devoted to manage RRM within a WLAN access network. However, pros and cons of the tight and loose coupling architectures will be addressed in EVEREST from the point of view of Common RRM. Besides, although loose coupling seems to be the preferred solution in both the WLAN and 3GPP communities (TS 23.234), integrated CRRM in tightly coupling architectures are also envisaged within EVEREST project.

REFERENCES
[1] G.Fodor et al. “Providing Quality of Service in Always Best Connected Networks”, IEEE Communications Magazine, July 2003
[2] Wei Zhuang, et al.”Policy-Based QoS Management Architecture in an Integrated UMTS and WLAN Environment” IEEE Comm Magazine, November 2003.
[3] B. Teitelbaum, et al, “Internet2 Q- Bone: building a test-bed for differentiated services”, IEEE Network, September-October 1999