Any-Constraint Personalized Network Selection - Semantic Scholar

1

Any-Constraint Personalized Network Selection Vítor Jesus, Susana Sargento, Rui L. Aguiar Instituto de Telecomunicações, Universidade de Aveiro, Portugal [email protected], {ssargento, ruilaa}@det.ua.pt

Abstract— In densely covered areas and with multi-interface terminals, network selection is a complex problem, especially if it takes into account different criteria such as context and signal strength. We present an algorithm that allows a mobility decision manager to consider arbitrary criteria such as user history or preferences. Since a typical mobility module uses quantitative and well-known information (eg., radio signal strength or available resources), qualitative information must be fed into the mobility subsystem only after converting it to a suitable format. Our algorithm uses (up to) three stages to produce a decision: first, it discards unsuitable possibilities; second, it produces a set of possibilities considering resource availability; and third, the feasible possibilities are ranked according to contextual information.

I. INTRODUCTION

C

urrent personal communications, such as voice or instant messaging, are under transformation due to two main reasons. First, it’s becoming usual to see mass-consumer devices with multiple network interfaces. Second, radio coverage is becoming dense and ubiquitous, especially in urban scenarios, not only due to the amount of accumulated investment so far but also due to the ease of access to technologies such as IEEE802.11 (“WLAN”), WiMAX, UMTS or even DVB. These scenarios pave the way to everywhere connectivity and high mobility. Such pervasive connectivity will increase the expectations of the regular user that, beyond simple connectivity, will want high Quality-of-Experience (e.g., minor service disruptions or smooth video calls). To this aim, one line of research has recently emerged – sometimes termed Always Best-Connected (ABC) paradigm [1]. In ABC, the central question is how can mobility – in wide sense – be managed in order to provide the maximum Quality-of-Experience to the user? One way to approach the problem is to support personalization and context in mobility management. Such support should be able to provide the mobility subsystem with ways to handle arbitrary criteria that may range from classical radio strength considerations to contextual consideration such as personalization and location. This paper discusses this multiple and arbitrary criteria at the mobility layer of networks. From a top-level view, the problem is mapping a flow to an access point, considering not only available resources (e.g., for QoS concerns) but also the circumstances that triggered the decision algorithm. For example, consider Fig. 1 and assume that a user (in the car) has a terminal with three interfaces: WiMAX, UMTS and WLAN. From Fig. 1 one can see that a single WiMAX cell covers the whole region and, hence, no handovers are needed. However, if UMTS is used, several handovers will occur; for the WLAN case, even more handovers will occur. In this case, it is clear that, in the absence of other criteria, the user should handover all its flows to the WiMAX interface. To arrive to this conclusion, one needs to correlate the movement of the car (constrained by the road) with cell planning.

978-1-4244-2644-7/08/$25.00 © 2008 IEEE

To further show the use of other type of information that impacts mobility management, consider now that WiMAX is very expensive, WLAN is cheap and UMTS is in between. Now, what seemed the best solution for the terminal (handover to WiMAX), may end up being the worst decision. If the user does not mind to have instability in the connections (e.g., a flickering video call) but only cares about cost, the WLAN interface should be chosen. This paper proposes an integrated, flexible and systematic framework that is capable of handling any type of criteria, differentiating users and decoupling several independent properties of the selection process such as admission control and negotiation. We do not focus on any special criteria or admission control process but, instead, on the framework itself. In section II, we discuss the problem and review related work. In section III we introduce key concepts that will facilitate the presentation of our scheme in section IV. In section V we evaluate our work and section VI concludes our paper.

Fig. 1. An example scenario: given all the possible flow handovers, how should mobility be managed?

II. PROBLEM STATEMENT AND RELATED WORK To help us explain our approach to the problem, Fig. 2 shows the multiple perspectives of network selection. The overall aim of a network selection scheme is the ability to provide intelligent and managed mobility and, thus, increase the Quality-of-Experience (QoE) of users, in a personalized manner.

Fig. 2. Multiple perspectives of the Network Selection problem.

2 A. Problem Partitioning We broke down the problem in state handling, resource management, mobility execution and real-time cooperation. 1) state handling State handling refers to the process by which all types of information (including those not directly related to mobility) are obtained and processed in order to influence mobility management. This includes classical state information (notably, link quality such as momentary signal strength) and also context (e.g., location or time). Many sources of context exist that can be connected to mobility and used to increase QoE [1][3]. As shown in Fig. 2, we classify state according to user (e.g., user at work or office), network (e.g., load history) and environment (e.g., time). The problem of adding relevance to this type of information is that it may not be natively understandable for the mobility subsystem. Consider again Fig. 1. In the absence of other criteria, location and terminal movement can be used to acknowledge that the best PoA is the WiMAX one. However, considering that monetary cost is also to context, how can we balance monetary cost and the location indication? In simple terms, how do we “add” up different constraints in order to produce an objective and unambiguous outcome to use in a handover decision? The focus of our work is not to model each context source but, instead, the way to handle it, once each context trigger is in a suitable form. For example, Iera et al. [3] provide a good analysis of some context sources using cost functions. 2) resource management The second part is the resource model. There are here two main lines of research that differ in the way the concept of “service” is considered. One approach is to put effort on the selection of the best PoA1 regardless of the underlying service; the other approach, uses admission control techniques and assess if a chosen PoA can serve the running services. We follow the latter philosophy since, while covering the other case, it is akin to commercial network planning. In fact, we use the concept of service mix (or capacity regions) [4] whereby an n-dimensional graph is the base of the admission control algorithm. In such graphs, each dimension is a well-defined service such as “elastic” or “voice”. Nevertheless, it is out of the scope of this paper to elaborate on the best admission control. We only assume that there are such mechanisms inherent to the network. A further consequence is that we separate resource management from quality decisions: whereas we consider resource management as an eliminatory and binary decision (service available or not), we’ll use other criteria to rank feasible options. In the example of Fig. 1, “movement”, “monetary cost” and “handover effort” are used to rank the options; but, if rank is obtained by evaluating several criteria, resources determine which possibilities are feasible and, hence, of interest to be ranked. Table 1. Availability of information (T: terminal; N: network). input N T input network resources √ network policies terminal resources √ user subscriptions booked actions √ grade-of-service interface suitability √ √ local context handover effort √ user history/preferences handover imminence √ √ terminal capabilities 1

Point-of-Access, (IEEE 802.21 terminology); we also use “Access Point” (AP).

N √ √ √ √ √

T √ √ √ √ √

3) mobility execution Mobility has been a hot topic for quite some time, especially, IP mobility which poses research challenges mainly due to the current routing architecture of the Internet. In this paper we speak of flow mobility: each terminal may split a connection between several PoAs. We assume that the granularity of handovers is the 5-tuple: addresses, ports and transport protocol. The per-flow approach, besides being friendly to transport protocols (e.g., TCP, UDP or even SCTP), provides an irreducible unit for resource allocation processes. In this sense, flows are objects of different sizes that are to be fit into “boxes” (Access Points) of variable sizes (available resources). It should also be noted that the granularity of a flow directly impacts complexity raising a tradeoff between simplicity of allocation (e.g., per-application flows) and effectiveness of the optimization [5][6][7]. 4) real-time cooperation Another important component that, typically, is not discussed is what we call the separation of powers. By this we mean that the availability of information is split between terminals (both directly and in representation of the user) and the network. Table 1 illustrates the concept by showing that information relevant to each handover is, actually, split between the network and the terminal. For example, whereas only the terminal can tell which PoAs is detecting at a particular moment, only the network can tell what available resources there are for those PoAs. In order to have robust mobility, both network and terminal must negotiate and exchange information in real-time, presenting each view at any moment. In terms of a mobility architecture, it means that a real-time protocol is needed so that the terminal reports its status to the network and the network requests information from the terminal. B. Related Work In this section, we review related work; in section C we set our requirements and briefly compare selected related work. Some work has already been done which explores the described optimization problem. The most common approach is to center the selection process on radio signal considerations (e.g., [8]). As discussed, despite its importance, we consider that it is only one between many criteria to be accounted for network selection. It is also common to consider link quality metrics (such as delay or bandwidth) – e.g., see [9]. Song et al. [12] also use Grey analysis in a mix WLAN/UMTS environment, being the main metrics for decision the QoS desired of the user or application and the current conditions of each technology (WLAN or UMTS). As we said, we depart from this model of selection since, as discussed, we adopt a model of discrete services. Hence, we’re closer to Gazis et al. [5] and Xing et al. [6] that model the problem of flow allocation as a knapsack problem: a user has applications to distribute across available PoAs. However, their work views mobility mainly as a resource problem, whereas we consider it to be only a part in a complete scheme for network selection. Combined criteria not related only to signal strength or link quality have also emerged recently such as Iera et al. [3], McNair et al. [10] and Chen et al. [11]. These authors propose schemes that are based on cost functions that contribute to an overall cost function which will, in the end, determine the best (under the selected criteria) PoA to handover to.

3 Table 2. Comparison of selected schemes for network selection.. “Ad.Ctrl”: Admission Control; “any crit”: any criteria; “s.of.p.”: separation of powers; “many trig”: many triggers; “unkn”: unknown independent profile Ad. any per many local (User/Resources/ Infrastructure) s. of p.? Ctrl crit? flow? trig? opt? U/I R/I U/R [1] [2] [3] [5] [6] [10] [11] [12] our

no no yes yes no no yes yes yes

yes yes yes yes yes yes yes yes yes

unkn unkn unkn unkn unkn unkn unkn unkn yes

unkn unkn no no unkn unkn no no yes

unkn unkn no no unkn unkn no no yes

unkn unkn no yes unkn unkn no yes yes

yes yes yes no yes yes yes no yes

no no no no no limited no no yes

no no no no no no no no yes

C. Key Requirements and Global Perspective of Related Work We state now the requirements that have guided our design: (i) strict service admission: clear separation between runtime admission control and quality information. (ii) easy plug-in of arbitrary criteria. Any type of information should be possible to use, as long it is in a suitable format. (iii) flow granularity. A flow should be the basic element. (iv) separation of powers. Terminal and network should exchange information and not attempt unilateral decisions. (v) fast environments. Support to queues of events. (vi) user optimizations. For scalability reasons, a scheme should support local optimizations (single user) and global optimizations. (vii) clear separation of entities based on self-contained properties. We have identified the following three entities whose properties should not be dependent on each other’s: network infrastructure (e.g., reliability of a PoA), the user/terminal (e.g., preference for low monetary cost) and resource constraints (available resources or not in a PoA). The review of the literature shows that, to the best of our knowledge, no scheme copes with all requirements (Table 2). III. BACKGROUND We first describe our general guidelines and then introduce some key concepts before fully describing our scheme in section IV. A. Design Guidelines Our main goal is to provide a scheme that, upon a generic event, produces a ranked list of feasible handover possibilities. These events can be nearly anything: change in the location, a service request (with QoS), time of the day, etc. The final result is to obtain a flow map [7]: a data structure that maps each flow to a set of PoAs and associates a quality value to each one. This involves the following issues:
trigger identification and processing. This issue is fully dependent on the specific mobility architecture: a scheme should be able to cope with any kind of external trigger. Examples of such stimuli are timely ones (either periodical or scheduled) or environmental (context).
ranked lists. Handovers possibilities should be produced associated to a value tightly bound to the Quality-of-Experience (QoE). Notice that QoE is typically bound to “computerunfriendly” concepts – such as the user personality – so the effort of ranking choices can be extremely complex. In order to manage this complexity, we identified the following three main

elements to model: the user/terminal, the installed base of PoAs and the context. Concerning PoAs, we have identified the following properties: ⋅ static properties such as reliability or geographical location ⋅ supported services and real-time availability of resources at each PoA under consideration (pseudo-time-dependent) ⋅ (pseudo) time-dependent properties such as easiness of handover to it from the current PoA the flow is allocated to. Concerning the user, we identified the following: ⋅ the static user profile, typically built after marketing models and owned by the network (e.g., user values price and doesn’t mind to have sporadic QoS violations) ⋅ the real-time context and preferences coming from the terminal (e.g., “prefer UMTS and not WLAN due to lack of resources in the WLAN interface”). Notice that this last item enforces the discussed separation of powers philosophy, allowing the network and the terminal/user to full negotiate so that handovers are not unilaterally decided [7]. Finally, concerning context (in widesense), all types of information that help to or decide mobility should be allowed in the scheme.
the set of feasible PoAs. Resource management is fully decoupled from the ranking procedures: only the set of possible flow maps, in terms of resources, are ranked and ordered. In this sense, resources act here as filters and not as quality information. This reflects our design decision to model resources in terms of services and not in terms of traffic metrics (such as delay, bandwidth and jitter). This decision has two main advantages: first, it is close to operator environments, where our research is focused; second, resources are modeled in abstract and, thus, they are technology independent; and third, they can be managed using policies. B. Separating Properties: PoAs, users and resources We found that matrix formalism is suitable to describe our algorithm of network selection. This section shows how we decouple the three orthogonal dimensions of the problem: the PoAs, the users and resources. We start by the following definitions:
let
be a terminal that belongs to the set of all  terminals that may execute a handover; specifically,
∈ K and #K = K
let M0 be the set of all possible PoAs, M1(k) be the set of all detected PoAs by terminal
, and M(k) the set of PoAs that the terminal
is effectively allowed to connect to (e.g., user has a valid subscription); and let #M(k) =  . For simplicity, we will frequently drop the index whenever possible and will say that  is the number of effective PoA candidates to be part of the flow handovers, for a certain terminal.
let  be the total number of properties of a PoA that will participate in the ranking step.
and let F (k) be the set of all running flows of terminal
so that #F (k)=
be the number of running flows. For simplicity, we will drop the index whenever possible to say that a certain terminal has flows running.
a flow map is a function that maps each of the  flows of a terminal to one and only one PoA out of the  possible:

4

 () : F (k) → M(k). It does not need to be an injective function since more than one flow can be mapped to the same PoA. We now define a set of mathematical objects that will be used to manipulate real-time constraints and produce a ranked set of flow maps. In order to clearly decouple the independent properties of the network selection scheme, we define three mathematical objects: PoA profiles (containing properties only related to each PoA), flow maps (related to the user activity) and user profile (independent of properties of PoAs and real-time activity of user). 1) PoA Profiles First of all, we define a PoA profile matrix:  =  ×. This matrix will store the properties discussed in section III.A according to the desired criteria that the network designer considers to be of value for mobility management. To keep the scheme architecture independent, we don’t specify a method to set the mapping between numerical values and properties. However, one can use the technique of [3] that consists of analyzing each criterion independently and use empirical values and/or empirical cost functions to set a value for all criteria. Since this matrix holds the properties of all  properties of all  candidates, we define its structure as the following:  = ()  (

)

 (!"#) $×%

The first part is the user part that comes directly from the terminal. The terminal can insert here any kind of information such as its preferences while, at the same time, not disclosing its metrics for PoA evaluation. The second part (static part) corresponds to properties of each PoA that are static, i.e., independent of context or time. Reliability or monetary cost for the user (if fixed and not dependent on the user) is an example of such metrics. The third part holds the real-time part that only the network knows. Since different criteria may have very different scales for its values, we define a new matrix that normalizes :  ([5] can be used for this). Going back to example of Fig. 1, if the monetary cost doesn’t change with time-of-day and for each user (or classes of users), we could have a matrix similar to the following, assuming the terminal has reported three PoAs and they are all allowed and good candidates for handover (best if closer to 100): Table 3. Example of properties of PoAs mob. from monet. handov. user cost effort prediction  100 50 60 17 50 60 17 UMTS_2 100 = & 80 10 10 100. 10 10 100 WiMAX_3 80 40 80 60 6 80 60 6 WLAN_10 40

For example, the values for “mobility prediction” illustrate the scenario depicted in Fig. 1: the WiMAX cell has a metric of 1 (1 cell), UMTS has a value of 6 and WLAN a value of 16. Upon normalization to 100,  of Table 3 is obtained. 2) Flow Maps A flow map is a mapping of flows to PoAs:

(,!) =  0 1×$ , such that 0 (,!)

(,!)

∈ 20, 13, ∀, 

The 5 index denotes a flow map for a given terminal
. Since we defined flow as the minimum indivisible unit of resources: (,!) ∑$ = 1,  = 1, … , . 078 0

As said, we’re not concerned with the actual admission control, although it is a core feature or otherwise our scheme cannot be practical. A generic discussion on this issue can be found in [7]. 3) User Profile The user profile part must capture the user properties that are not dependent on context or real-time activity. We modeled it as an equalization process over the PoA properties: :() = (:0 )%×% such that :0 

()

()

= 0 if  ≠ .

: is a diagonal matrix whose elements show, for a particular user profile
, what PoA properties should have more importance than others. Imagine two such profiles, “business man” and “teenager”, and consider the PoA properties of Table 3. Imagine also that a “business man” (BM) mostly wants unperturbed communications (meaning, reliability and seamless mobility), wants the network to manage his mobility (terminal preferences are de-valorized) and monetary cost is moderately important; and that a “teenager” (T) cares, above all, about monetary cost. For each user class, a : could be the following, using equalization factors such as 0 (“doesn’t care at all”), 0.5 (“cares little”), 1 (moderately important) and 1.5 (“very important”): business man teenager

user prefs 0.5 0.5

monet.cost 1.0 1.5

In this case, the : matrices become :(BM) = @

0.5 0 0 0

0 0 1.0 0 0 1.5 0 0

0 0 A 0 1.5

HO effort 1.5 0.5 0.5 0 0 0

: (B) = @

mob.pred. 1.5 0.5

0 0 1.5 0 0 0.5 0 0

0 0 A 0 0.5

In order to incorporate the concept of user profile into a PoA profile, we define  ::  :0 $×% =  0 $×% × :0 %×%.

Using the previous example, the equalized  s become: 50  : (BM) = &40 20

50 10 80

90 15 90

25.5 150 . 9

50  : (B) = &40 20

75 15 120

30 5 30

8.5 50 . 3

In this way, criteria importance is equalized according to a user profile. In a real commercial environment, the : matrices are likely to be obtained using marketing tools such as user profiling. IV. PROPOSED NETWORK SELECTION SCHEME We are now ready to present our scheme for network selection – see Fig. 3. It has four main phases: (i) trigger management and processing, (ii) classification and prioritization, (iii) calculation of a set of ranked connectivity plans (try for a single terminal; if not possible, for a group of terminals) and (iv) handover initiation. A. Trigger Management Although a complete taxonomy of event sources is out of the scope for this work, one can think of three types of events: realtime events, scheduled and periodic. The first type is represented by the top-left corner of the diagram. Since complete information regarding the current communication state is split between the network and the terminal, both parties need to exchange perspectives. The diagram of Fig. 3 shows the network contacting the terminal (dashed arrow) and the terminal reporting information. It is also supposed to illustrate the situation where a change in context (wide sense) occurred. These changes can be

5 detected by the network or the terminal so that any party can start a handover process. The second and third types of events (topmiddle and top-right) are either periodic actions (e.g., denying access at a certain hour of the day) or scheduled actions. termin al

networ k

repor t user

periodi c

trigger

schedulle d

trigger

trigger

aggregate & update user’s state

real-time user’s quality conditions information - network planning error? - bad configuration? - inaccurate information?

static

at least a user has no solution

no n solutio

request candidates from other users

(APN )

user

ij M ×W

filter unsuitable APs for each user

(APNU )

ij M ×W

(APN ) (APNU )

ij M ×W

(CAPi )M ×1

ij M ×W

find flow maps: try minimal CAP; if not, full CAP

admission control

(FM ) (APA )

(CAPi )M ×1

no solution

(k )

found flow maps

ij N × M

ij K × M

no solution: try global

(WFM )

find flow maps: try minimal CAP; if not, full CAP

ij K ×1

(FM ) (APA )

admission control found { ( )} flow maps

(k ) ij N × M

ij K × M

(WFM )

ij K ×1

best

send to terminal: by order of classification

send to each terminal: best by order of classification

Fig. 3. Our Network Selection Scheme.

B. Classification and Prioritization Once a trigger is generated, it is classified and inserted in a common queue for processing. A queue allows trigger differentiation, both in terms of trigger type and trigger owner. Regarding trigger type, we use two queues: urgent situations (e.g., terminal loosing signal) go to a Real-Time (RT) queue; nonurgent situations go to a queue named non-Real-Time (nRT). The main difference is the time needed to serve the request (e.g., 200ms for RT). The queue may also support user differentiation. This is useful in case of resource constraints: when determining flow maps, premium users should get their top choices. Section V (evaluation) will show how this design choice can be effective. C. Flow Maps Calculation We enter now the stage where the algorithm calculates flow maps. There are two branches: local optimizations and global optimizations. Whereas the first concerns a single user, the second concerns the full optimization of a sufficiently large area and number of users. The distinction made is due to a simple reason: the (expected) heavy processing of the scheme. It is expected that, if not designed correctly [7], already single-user optimizations can be computationally heavy. We will describe the single-user branch (global branch is conceptually similar). This stage consists of algebraic manipulations of the matrices we have previously described and consists on the following steps: 1. Obtain a normalized version of  to generate  .

2. Find to which group the user belongs, retrieve the group profile and generate  :.

3. Generate F using (F )$×8 = ∑% 078  :0 ∶ this is the overall cost of each PoA, already normalized and personalized. 4. Using the network’s database of resources (must be updated), find the best H flow maps as described in section III.B.2), according to the service mix deployed in the network. Our scheme support non-exhaustive algorithms: in order to reduce complexity, some PoAs may be concealed (which we called “minimal CAP”). This can be realistic in case the network is known to be always lightly loaded; if not, all solutions should be found to avoid running out of options.

5. (optional). In case no flow maps were found, generate alarm to network administrator and try a global optimization. This is conceptually similar to the case of a single user with the difference that now all flows from all users considered must be tentatively allocated to the reported PoAs (with the special constraint of not all users will see the same PoAs). The selection of terminals that belong to the group can follow many strategies; perhaps the most obvious is by geographical location and currently in reach of a set of PoAs known.

6. Suppose we have found H flow maps. Generate matrix “PoA Allocation” for each flow map found: () (0 )I×$ = ∑1 (  ) . This matrix determines how much #78 #0 used a certain PoA is for each flow map. 7. Determine the ranking of each flow map by generating the matrix   (“weights of flow maps”) using (  )I×8 = (0 )I×$ × (F0 )$×8 .

8. Find in   the top J best ranked flow maps. The quality M value of a flow maps is defined by K = NOP%L$ . (%L$ ) M

D. Mobility Initiation The best J flow maps should be sent to the terminal(s). Each terminal should receive the set of flow maps ordered by rank. It is up to each terminal to select a flow map according to undisclosed or local policies. It must, however, choose one from the set of offered ones; otherwise, all calculations must be done again. V. EVALUATION Fig. 1 shows the scenario we used to evaluate our scheme. The simulation tool we have designed incorporates the rules of diagram of Fig. 3. Imagine that three people are traveling and that, at a certain moment, their connectivity is to be optimized (e.g. due to a periodic trigger). There are three available cells available for all three users: a UMTS cell (U2), a WiMAX cell (M3) and a WLAN cell (L10). Imagine also that each of them has two flows to handover and that U2 and M3 cells have 2 units of available resources and L10 has 3 units of available resources. To simplify matters and without loss of generality, consider that all types of flows use 1 such unit of resources. Let the properties of each PoA be as in Fig. 4. On the left, it is shown the default properties of each PoA ( ) and, on the right, all possible flow maps for each user (they are the same since they are all using 2 flows of equal size). The three PoAs are very heterogeneous: whereas the WiMAX cell is strong in the mobility criteria (no handovers at all), WLAN is cheap and UMTS is a balanced

6 choice. Now imagine that the three users are a salesman salesman, a gamer and a music fan (“groupie”).. Further, let’s assume that the user profiles for each user are as depicted in Fig. 5 top:
the salesman wants predictability from th the network at a reasonable price: its : sets “mobility” and “reliability” to 1.5 and “monetary cost” to 1.0.
the gamer corresponds to an idea of “performance at all cost”.
the groupie wants cheap connectivity.

a full network stack. Many open questions are raised of which the most important are scalability ity and performance.

Fig. 4. Properties of candidate PoAs for our evaluation scenario. left: PoA profiles; right: all possible flow maps (the the same for all three users).

VI. CONCLUSIONS AND FUTURE WORK We have described a new scheme that allows a network to manage its devices connectivity based on virtually all types of criteria, including context, user preferences and user profiling. We have identified three vertices of the problem, oblem, namely, user, PoAs and resources, and have developed a linear scheme that uses matrices formalism. This work is a continuation of a previous one [7] where we first described the problem in general terms. With W this paper, we describe in detail the algorithm component and address some preliminary results. We intend now to evaluate our scheme using

Q=0.80

Q=0.88 conversational

UMTS

conveersational intera er ctive Q=0.96

UMTS

gamer

gamer

Q=0.78 groupie

salesman

salesman

salesman

WiMAX

Q=1.00

i nt er ela alacstitivcing seti ame strec

Q=0.86

inteeractive e elastic

WiMAX

Q=0.97

random Point-of-Access allocation

elastic

WiMAX

elastic streaming

WLAN

groupie

groupie el ic elast streeaming

WLAN

UMTS conversational ve i t c emergency call era gamer int e tiv ac ter in

B. Reconfiguration after an Event Now imagine that, after all users did the suggested handovers, an emergency call arrives that, by some reason, the network must allocate to the WiMAX cell. Since the gamer user is occupying that cell, a global optimization must be initiated. Data in Fig. 4 and Fig. 5 are still valid but now, for each user, a new set of flow maps must be chosen. The best global configuration, attending that gamer has priority over salesman, is shown in Fig. 6-right. As seen, this caused a heavy reconfiguration but, however, the quality indices of the choices remained higher than Fig. 6-left (worst-case case using random network selection) selection).

Fig. 5.. Mapping flows to PoAs for the three users and intermediary matrices. The relative priorities are gamer>salesman>groupie. game

e tiv ac ter in

A. Global Optimization Fig. 5 shows the application of our scheme to the described scenario and considering that a global optimization is needed. needed In the end, we have the matrices  .. One can see that for both the salesman and the gamer, the best ranked flow map is the fifth (two flows allocated to WiMAX).. However, since the cell can only hold two flows, one of them must use the second best ranked flow map. Assuming the “gamer” class of user has highest preference (“premium”), and since the three triggers trigger (one per user) arrived at the same time, the gamer is served first. This means that, by the time the salesman trigger is served, its flow map options won’t contemplate the WiMAX cell since it is already fully booked. His best option is, then, the third flow map. The groupie, concerned with monetary cost, will handover many times, but at low cost. Fig. 6 shows these dynamics: dynamics Fig. 6-left a worst-case allocation of flows (e.g., from a random rando scheme); Fig. 6-center shows the allocation of flows using our scheme.

WLAN

Q=1.00

Q=1.00 our scheme

our scheme: global reconfiguration after emergency call

Fig. 6. Dynamics of our test scenario: (left) (left worst-case allocation of flows; (middle) optimal; (right)) optimal allocation when a priority flow arrives.

REFERENCES [1] E. Gustaffsson, A. Jonsson. Always Best Connected. Connected IEEE Wireless Communications, unications, Vol. 10, No. 1, pp. 49-55, 49 Feb. 2003 [2] Prehofer C et al. A framework for context-aware context handover decisions.In IEEE Intl Symposium on Personal, Indoor and Mobile Radio Comm, Comm Beijing, Sept03 [3] A. Iera et al., An Access Network Selection Algorithm Dynamically Adapted to user Needs and Preferences, Proceedings of IEEE Intl Symposium on Personal, Indoor and Mobile Radio Communications, Communications Helsinki, Sept06 [4] A Furuskär, J Zander, Multiservice Allocation for Multiaccess Wireless Systems, IEEE Trans on Wireless eless Communications, vol 4, no. 1 Jan 2005 [5] V.Gazis, N.Alonistioti, and L.Merakos, Toward a Generic "Always Best Connected" Capability in Integrated WLAN/UMTS Cellular Mobile Networks (and Beyond), IEEE Wireless Comm, vol. 12, no 3 (Jun), pp. 20-28, 20 2005. [6] B Xing and N Venkatasubramanian,Multi-Constraint Venkatasubramanian, Dynamic Access Selection in Always Best Connected Networks, IEEE MobiQuitous’05, CA, July05. [7] Vítor Jesus, et al., Mobility with QoS Support for Multi-Interface Multi Terminals: Combined User and Network Approach, Approach IEEE Symposium on Computers and Communications, July’07, ’07, Aveiro, Portugal [8] K. Pahlavan, P. Krishnamurthy, A. Hatami, M. Ylianttila, J.P. Makela, R. Pichna and J. Vallstron, Handoff in Hybrid Mobile Data Networks, Networks Personal Communications, vol. 7, pp. 34-47, April 2000. [9] E. Stevens-Navarro Navarro and V. W.S. Wong, Comparison between Vertical Handoff Decision Algorithms for Heterogeneous Wireless Networks, Networks in Proc. of IEEE Vehicular Technology Conference (VTC-Spring’06), (VTC Australia, May06. [10] J. McNair and F. Zhu, Vertical handoffs in fourth-generation fourth multinetwork environments, IEEE Wireless Communications Communications, vol. 11, no. 3, pp. 8–15, 2004. [11] W.-T. Chen and Y.-Y. Shu, Active application oriented vertical handoff in nextnext generation wireless networks, in Proc of IEEE Wireless Communications Co and Networking Conference,, New Orleans, USA, Mar05. [12] Q Song, A Jamalipour, Network Selection in an Integrated Wireless LAN and UMTS Environment using Mathematical Modeling and Computing Techniques, Techniques IEEE Wireless Communication 12(3):42-48, 12(3):42 June 2005.