Multiple-Media Session Management

К оглавлению
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 
34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 
51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 
68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 
85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 
102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 
119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 
136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 
153 154 155 156 

While the automatic view on session management is the dominating rationale for

single-media applications, this view is even stronger when it comes to media

switches during ongoing sessions (e.g., American National Standard for

Telecommunications, 2001). The standard approach to media switches is to let

a system automatically hand over a session from one platform to another

(Buford et al., 1998). As implemented in mobile phone networks, for instance,

handovers are executed automatically when the phone receives a better signal

from another station (sometimes denoted as ABC or “always best connected”).

In what follows, we illustrate how the automation view in multiple-media

session management can be increasingly problematic on the user level. Consider

the following examples:

Example 1: Within a few years, people are likely to subscribe to several

wireless networks such as W-LAN, W-CDMA and GSM. W-LANs

cover “hotspots,” W-CDMA the entire city, while GSM may be the only

network available in the countryside. In part, these networks will cover the

same areas. For example, users will be able to use GSM in the city. In such

a situation, they will probably not want the mobile terminal to select

network connections automatically. If the GSM network has enough

bandwidth for your phone call, then why use the more expensive WCDMA?

Most people would probably want to continue the phone

conversation using the (less expensive) GSM network.

Example 2: It is increasingly common to use W-LANs in the office, which opens

up new possibilities to have mobile Internet access. For example, it

simplifies the task to provide handheld computers with useful content.

Consider that you are in the office and start to download MP3 files. In this

situation, the question is whether you want your handheld computer to

continue to download music using the GSM or W-CDMA networks when

leaving the office (recall the ABC principle)? Probably not, since it would

cost you or your employer too much. Thus, you probably want the

download to interrupt when leaving the office. Likewise, you may want the

download to resume when you get back to the office, because then you

have inexpensive wireless network access again. It is important to note,

however, that in other situations (perhaps when important and timecritical

documents are downloaded) you might want the download to

continue using the GSM or W-CDMA networks when leaving the area

with inexpensive network access.

As these examples show, automatic session management is problematic in that

it is difficult for designers to implement rules that apply to all use situations.

Whereas automatic media switches can be convenient in terms of the limited

overhead work required, they can also be ill suited to the specific situations in

which users find themselves.

Research Method

The research presented in this chapter was conducted as a collaboration

project involving academics at the Viktoria Institute and practitioners at a car

manufacturer (Saab Automobile), a mobile telecommunications network company

(Vodafone), and a systems integrator (Mecel). We used the principles of

the “task-artifact cycle” (Carroll, 2000). Intended to be a mediating structure

between development processes and technology-in-use, the task-artifact cycle

helps generating the requirements that can seed system design. More specifically,

the rationale of this cycle is to capture and structure user requirements of

a system by identifying the use cases and detailing all the scenarios that users

will perform (within these use cases). A use case can therefore be described as

a collection of possible sequences of interactions between the system and its

potential users.