A Policy-based Approach to Personalization of

A Policy-based Approach to Personalization of Communication over Converged Networks Patricia Lago Dipartimento di Automatica e Informatica, Politecnico di Torino, Italy [email protected] Abstract The continuous evolution of the Internet and computerized technologies contribute to make technologybased communication more complicated and difficult to master. In turn, users become more demanding and better informed about real provider offers for added-value services and features that allow the integration or the interoperability of different applications, devices, and terminals, possibly acquired from multiple providers. In this scenario, “personalization” represents the possibility for a user to filter incoming communication requests, and to process them according to personal preferences and lifestyle. This paper describes a policy-based approach to personalization. The basic idea is to use a generalized useroriented policy concept, at a higher level of abstraction than policies in networking. User-oriented policies define how communication should be handled by software architecture, according to a user-oriented perception of services, and abstracting from heterogeneity like difference in networks, communication protocols, applications, and devices/terminals. Due to the high-level policy-based approach we have used, we may apply personalization also to advanced scenarios like services over converged networks: in our approach, policies represent personalization in an abstract way, and network and service technologies are transparently integrated in a component-based software architecture to which personalized communication is delegated. Our policy-based approach also shows how policies can be profitably applied in a context different from networking.

1. Introduction Personalization is a concept applicable to many and different contexts. In this work, we use the definition given in [16], and summarized as: Personalization permits to adapt a service in a specific context and to individual goals, by providing the users with a high-quality product or service they really need and can use at “best”. Further, we apply personalization to telecommunication support, and consider it as the way a user can filter incoming communication requests according to personal preferences and lifestyle.

To better focus our concerns, let us consider two completely different examples of communication types and their personalization. Intuitively, by speaking of communication we think of two or more people talking together, supported by some communication device, like phones on a telephony network or audio applications on the Internet. Of course we may want to personalize the way communication is handled (e.g. if the communication request should be immediately processed, or instead if it should be filtered by some answering machine or prerecorded message), or we can decide the address where we want to be contacted (e.g. on the office phone rather than on a mobile device). Alternatively, communication can be perceived more in general, as some interaction carried out among people or with a computerized system. For instance, people can start a virtual workshop on a network of distributed machines: each participant may personalize the way his/her interaction is carried out (e.g. one person using a phone, another on a PC through a videoconferencing application, a third one through a chat application connected to a speech-to-text translator, etc.). Of course, each participant will have a personalized perception of the workshop (the first audiobased only, the second both audio and video (if present), and the third with textual translation. The overall advantage is (1) to be able to use personal settings, devices and subscribed services, and (2) to be able to carry out collaborative interactions independently from individual technical features or subscriptions. Further, we could personalize (or automate) the way we interact with a computerized system (like my Internet- or Service Provider), by pre-programming which services have to be activated in certain situations (e.g. e-mail redirection for working communications during holidays), or which terminals/services have to be used for certain interactions (e.g. my home Internet connection for my automated enewspaper download-and-print each morning). The instruments supporting personalization are userdefined policies, i.e. a set of guidelines to personalize service supply according to user criteria. Consequently, a policy should be intuitive and easy to define, so that a user can cleanly characterize his/her own personalization. In addition, as a policy represents an everyday usage scenario, it should have a rather course granularity.

Policy-based personalization represents a very powerful means to program any operational behaviour in a computerized system. Policies have been applied to diverse domains, from networking to software process modelling and data mining, thus demonstrating properties like generality and flexibility. Specifically, the context of this work is communication support over converged networks. By converged networks, we mean the possibility of transparently supporting any communication type, over any type of network and terminal [17]. Accordingly, we developed policy-based personalization realizing two overall objectives: service-common behaviour specification (i.e. abstraction from any specific service), and openness to network evolution (i.e. general applicability). This paper is structured as follows: after a description of the concept of service, Section 2 describes our policy-based approach to personalization and the mechanisms providing policy. For “policy evaluation”, we mean the analysis of a list of predefined policies, to find out if there exists a policy that is valid in the current state. Section 3 describes how our approach is implemented in a software architecture supporting communication over a PSTN-Internet converged network. Sections 4 and 5 discuss related work and provide conclusive remarks and directions for future work.

2. Policy-based Personalization In this work, personalization is based on two main concepts, service and policy. A policy provides the instrument to personalize the way services are supplied, whereas a service identifies a feature as perceived by the user, and for which (s)he has to pay. In the following, we explain how we perceive them, and how they have been adopted and modelled in our system.

2.1. The Concept of Service A service can be defined as “a specified set of capabilities provided to a group of users by a telecommunications system”. According to this definition, a service can be both “essential” like communication support given by a provider (e.g. Internet access), and “sophisticated” like e-mail functionality (e.g. message editing and sending typical of an e-mail application). For this reason, wherever not specified, we will use term service for both the user application and the overall functionality. As discussed thoroughly in the next section, an important aspect of policies is to be able to represent personalization independently from any specific service: the user wants personalization to apply even if the used service changes, or if new services are subscribed. For example, if a person is called on the phone, or from a videoconference application, or if instead an SMS or an email is to be sent, this person would like his/her personalization policies to be generally applicable. Moreover, if someone buys a new Internet device, or subscribes to a new communication

software application, his/her policies should be still applicable. To keep personalization service-independent, we applied the following rationale: As communication is always achieved through a service, we should define which services do support which communication type. Then, as the communication type can be easily generalized, we can define personalization in terms of generic communication types, whereas the specific service can be transparently resolved at runtime by the implemented system. CommunicationService

SynchService

AsynchService ........

AudioService

Telephony

VideoService

InfoService ........

DataService

AudioConference VideoTelephony VideoConference SharedWhiteboard

Chat

Figure 1. Classification of communication services To provide the mapping service vs. communication type, we defined the service classification exemplified in Figure 1. This defines communication in terms of its implementing service classes: under term “service class”, we mean a set of communication services sharing a logical affinity. For instance, PSTN telephony, Voice over IP, and audioconferencing are all services supporting synchronous, audio communication. For synchronous communication we mean the communication used by all services requiring an immediate response from the callee. On the contrary, asynchronous communication is typically message-based (e.g. email, SMS, fax) in which the callee is not compelled to interact with the caller real-time. Figure 1 proposes an example of service classification (drawn for simplicity for synchronous communication only). It defines a three-levels classification: existing and new services are inserted as leaves of the lowest level, hence automatically inheriting the communication type of super classes. For instance, by adding the Netscape Instant Messenger as leaf of class Chat the system will interpret it as a synchronous, data service supporting chat. Again, as leaf of class AudioConference, Microsoft NetMeeting it is a synchronous audio service, whereas as leaf of class VideoConference, it is a synchronous video service.

2.2. The Concept of Policy A policy can be intuitively defined as a set of guidelines, or a list of actions to achieve a certain objective. This definition can of course be applied to many different application areas and subjects. Specifically to the IT

domain, policies have been used to program patterns of actions customisable to ongoing situations. The core potentiality of policies is formed by this generality and flexibility, the reason why they are so powerful in complex and heterogeneous environments like converged networks. For instance, any non technical user is able to understand a generic policy like “redirect all incoming calls to my assistant if I am not reachable”, or “send me my favourite electronic newspaper daily at 7 AM”: details about how network resources and IT applications realize these policies can be transparently resolved. In fact, when the user defines a policy, we think that (s)he is not interested in how the policy is going to be provided: in the examples above, the user does not specify how the call is to be redirected, or how the newspaper is to be sent. Moreover, the user does not know where (s)he will be reachable when the policy will actually be executed: hence, in the examples, (s)he does not know where (s)he will be reachable when a certain call arrives, or where the newspaper is to be sent (at home on the printer, or on holidays in the mailbox). In other words, we identify the following policy properties: Simplicity: a policy should be easily comprehensible and in principle directly manipulable by any kind of user. Context independence: a policy definition should be independent from the state of the environment/context against which it will be evaluated and in which it will be executed, like the type of used terminals or networks. Application independence: a policy should abstract from the specific application available to the actors it involves. This abstraction permits to specify the desired behaviour without any constraint on the source of a communication request (which can be originated by an unknown user and from a remote domain), and without any constraint on the specific services currently subscribed by the user. Flexibility: the user should be able to decide the level of abstraction reflected in a policy. A policy could be left generic from specific terminals, networks and subscriptions, or it could be detailed to apply to more specific cases like for instance a call redirection to a specified phone number, or audioconference invitations forwarded to a specified IP address.

2.3. The Policy Structure In this work, the structure of Policy is inspired by rules in the more traditional ECA paradigm [2], in which a rule is composed of Event-Conditions-Actions: an event is an external stimulus addressed to the user; conditions represent constraints on rules scope; actions are operations performed if and only if all conditions of the rule are satisfied when the event occurs. Similarly, we define a policy as composed of events, conditions and actions. As in our work a policy

aims at personalizing service provisioning, events are used to model requests for communication; conditions represent situations set by the user; actions lead communication accomplishment. The policy structure is depicted in Figure 2: top-down, personalization of each user is organized in policy groups, each collecting a set of Policy instances logically correlated. A single policy is composed of a maximum of two events, a variable number of optional conditions, and a variable number of actions. In a policy, either the event can be issued from any external source, or the execution environment can internally generate it. User Personalization 1..* 1..* Policy Group 1..* 0..* Policy 0..*

1..2 Event

1..* Action

Condition

screening IntEvent

ExtEvent

redirection Time

scheduling CommunicationRequestType * *

Activation Time

Exception Type

mapping servicecommunication

Person

(from UserProfilePkg)

Type = Busy | No Answer | Not Supported

CommunicationService (from ServicesPkg)

Special Action Type

Terminal Address Type

Type = Stop | Play Recorded Message

Personalization Kernel for Comm unication

Figure 2. Policy structure As emphasized in the Figure, this part of our policy definition can be considered generic, and further customisable for a specific application context. Accordingly, we defined a specialized kernel for communication personalization. An external event (see specialization of class ExtEvent) models the arrival of a communication request, which can be for a synchronous call (e.g. phone call), or a message sending (e.g. e-mail), as explained in Section 2.1. An internal event (see specialization of class IntEvent) models either an exception representing the reason why the execution of a policy action failed, or the expiration of an activation time for a user-scheduled action. In the first case, the reason for the failure must be associated with the communication request. In the second case, the activation time is a stand-alone event triggering some actions. Accordingly, policy semantics has been defined for two policy types: • A single-event policy models straight personalization: when an external event arrives, if and only if all conditions apply, the actions are executed. Formally, the raising of an event activates

policy evaluation, and the validity in the current context of both event and conditions fires the policy, i.e. activates its actions. For example, the first policy in Figure 3 specifies that if the event is a communication request of type SynchService, and if the predefined time condition is true (i.e. the event is evaluated between 8AM and 5PM), then the call must be forwarded to the specified IT terminal. • An event-exception policy models personalization for exceptional cases: when a communication request cannot be served (i.e. if an exception raises during action activation), if and only if all conditions apply, the actions are executed. In other words, an eventexception policy can be fired if an exceptional situation occurs during the execution of a corresponding single-event policy. For example, the second policy in Figure 3 specifies that, if a communication request of type SynchService has been forwarded to the user terminal and this is busy, then the call must be redirected to user Erik. Back to Figure 2, conditions defined so far include the possibility either to restrict the scope of a policy to a timeperiod, or to implement call screening by identifying the caller identity or terminal address. As an example, policy number three in Figure 3 is conditioned by associating the caller terminal with number +390115647008: only in this case, the policy is fired. In addition, a minimal set of primitive actions and related semantics has been defined: • Action Person defines call redirection, i.e. the action is to redirect the call to another person, as exemplified in the second policy sample. • Action Terminal defines the type of terminal to which a communication request is directed. Current implementation supports four terminal types: PC, phone, mailbox and generic terminal. The reason for the latter will be clarified in Section 2.7. • Special Action is an atomic action supported by the provider with no involvement of the called user. Current implementation supports “Stop” and “Play Recorded Message” (both for call filtering). The primitive actions as defined above are explicitly bound to objective entities involved in service provisioning in generic terms (like the person involved in – or the terminal used for – service execution). In this way, we are able to decouple how services are put in operation, from the logical functionality provided by a specific service. For instance, we can model an audio conference by inviting multiple persons into a synchronous communication session, and still we can abstract from the specific application/terminal each partner will actually use. Further, three values for class Exception are foreseen: Busy, No Answer and Not Supported, the latter when a certain communication cannot be accomplished due

to technical problems (e.g. the caller and the callee terminal/network types are incompatible). The graphical representation of policies (in Figure 3) models events, conditions and triggered actions with visual symbols that should provide the needed metaphor to decouple technical details from high-level understanding of what each policy personalizes. Let us provide some examples. For events, two people directly connected are (as in policies number I, II and III) represent synchronous communication, while an envelope (as for the remaining policies) represents asynchronous (i.e. indirect) communication. Conditions on time or on the caller, are modelled by a clock or a person, respectively. Concerning actions, maybe the most complex entity refers to action Terminal. All terminals (PC, phone, mailbox) have an associated symbol, and can be either left unspecified (if we want to apply the policy to any terminal of that type), or associated with a specific terminal address. Moreover, an additional symbol labelled “Generic Terminal” (not used in Figure 3) models any available terminal, of any type. By identifying terminals, the system handling communication requests will automatically map which services are suitable to initiate the communication specified by the fired policy, according to terminal compliance and user subscriptions. I:

II:

III:

IV:

V:

Figure 3. Policy samples1 We believe that the policy language already allows the user to define a quite powerful set of policies personalizing services, and network behaviour. Of course, it requires a policy evaluation algorithm (presented in the following Section), and service and network architecture to make policy-firing possible on real execution scenarios (presented in Section 3).

1 The graphical representation of policy instances is taken from the GUI of the personalization service (see [14] for further details). Policy instances are represented and stored in XML, according to our XMLbased policy language.

2.4. Policy Evaluation Each user can define a set of policy instances, which specify how incoming communication requests must be processed. More precisely, each user can define multiple policy groups: only a single group can be active (i.e. used for personalization), while the others can be stored for reuse. As an example, a typical user could define a policy group for normal working periods, another group when (s)he is on holidays, and a third one when (s)he is on working trips. Of course, by having pre-defined policy groups for recurring occasions make personalization handier. Policy evaluation is the process of analysing a list of predefined policies, to find out if there exists one policy that evaluates to true, against the current state of the environment. Policy evaluation starts whenever an event occurs in the execution environment: the event is associated with the correct user, and his/her active policy group is evaluated to find a policy that matches the current situation. The evaluation algorithm performs the following general steps: Evaluate Policies from top to bottom For each policy: if ((events match) && (conditions match)) then process all Actions break 2exit % jump to end of algorithm fi As summarized in the fragment above, policy instances are evaluated top-down, until either the first matching policy is met (see loop termination at the break instruction labelled 2exit), or no policy is applicable. This is a rather simple algorithm, although it already reveals complex execution scenarios, as we will explain later on. Its main advantages are: 1. The user can program personalization as top-down cascading policies; 2. Policy evaluation resolves complicated execution paths (e.g. the problem of multiple matching policies is solved by simply selecting the first matching one). As an example, let us suppose that the sequence of policy instances in Figure 3 makes up the active policy group assigned to user Anna, and that a communication request of type SynchService arrives for Anna from phone number +390115647008. Policy evaluation analyses her policies from 1 to 5, and stops at the first valid one (i.e. matching both events and conditions). We can observe that all the first three policies match current event type. Further, policy I would match if and only if the event is evaluated in the stated time-period: we suppose that the communication request arrives at 7PM, so that this policy is not valid. Also for Policy II its events are not matching (no exception occurred). Finally, policy III matches both event and

conditions, and hence policy evaluation terminates successfully and the policy action is executed (i.e. the request is forwarded to a phone number). On the other hand, if we suppose that a communication request of type AsynchService is addressed to user Anna, during policy evaluation only policies IV and V match this communication type. Further, as policy IV does not prescribe any condition, it results to be valid, policy evaluation terminates successfully and policy actions are executed (i.e. the communication request is forwarded to mailbox [email protected] and a notification is sent to a PC terminal).

2.5. Algorithm Details The general behaviour of the policy evaluation algorithms holds the peculiarities here discussed. 2.5.1. Top-down Processing According to the evaluation algorithm, policies are processed in a top-down order (in our example, from policy I policy V), until the first matching policy is identified. This solution has the advantage of preserving simplicity, so that it is rather easy for the user to understand the logics modelled by the group of policy instances (s)he defined. Alternatively, we could implement more sophisticated approaches to policy selection, too. Nonetheless, these would not bring much contribution to the underlying objective of providing flexible personalization. Besides, a more complicated policy selection algorithm would decrease comprehensibility for the end-user. Another important advantage of our approach is to resolve in a simple way, situations like conflicting policies or completeness of covered scenarios, which are not immediate to identify. For instance, policy V in our example covers a specified time-period, while policy IV should cover the remaining situations. Nonetheless, policy V will never be evaluated, because it has been placed after policy IV, and policy IV has a broader applicability thus covering all situations. To cover all scenarios correctly, we need to move policy V before policy IV, which is not restricted by any condition. As discussed previously, it is rather easy to find out and avoid this kind of errors, by simply ordering policies topdown in a decreasing level of detail. 2.5.2. Action Semantics To keep policy definition generic with respect to services, the actions are defined in terms of the type of terminal (or termination point) where to address a communication request. This allows a user to change his/her service subscriptions, and keep policy instances invariant: dynamically, the system will discover which services can be used to actually carry out a type of communication.

However, the user might need to indicate in a policy instance the use of a specific service (or application). This is always possible by associating to an action, a specific service as attribute. For instance, in policy I of Figure 3, we can define which application is used on the IT terminal. The alternatives above have different advantages (and drawbacks): by selecting a specific service, implies that the user must be subscribed to that service. On the other hand, it also simplifies the setup of the associated communication service: as a specific service is already bound to a certain communication protocol, communication setup must only identify if that protocol is supported or not. If the action is left generic, communication setup has also to find out which among the available services is subscribed, and compatible with available network resources. 2.5.3. Execution of Multiple Policy Actions In a policy, the semantics currently associated with the list of actions is of type execute all: all actions are executed simultaneously. Of course, more sophisticated and programmable execution semantics can be defined, like to execute all actions in sequence, or to execute only the first successful action and then to stop. For instance, in the latter case, if the valid policy of our example were policy IV, the first action would instruct to contact the PC, and if this was not successful, it could terminate the call on a mailbox address. This extension is very dependent on the specific application domain, and it is subject to future work. In addition, to separate policy evaluation from execution of the matching policy, two distinct components have been developed. One component implements both user personalization support (i.e. for policy definition) and the policy engine (i.e. the component that returns the valid policy – if any), and another component implements communication handling (i.e. listening to communication requests and invoking the policy engine to discover the related action list). It is the latter component that associates semantics to policy actions, and that resolves an eventually hybrid communication according to the network resources available at the provider’s premises. 2.5.4. Dynamic Discovery of Policy non-applicability It can happen that during policy evaluation against an incoming event, no policy applies. In this case, basic semantics is defined to terminate on traditional behaviour, i.e. to try to contact the callee on the terminal type most suitable for the type of communication request. To this aim, when no policy applies, the evaluation algorithm is extended with the behaviour described in the second algorithm fragment (see box below), in which: The user can inject a set of Registrations, i.e. a (list of) terminal address(es) by which (s)he is currently available. For example, if the user is abroad and wants to be temporarily traceable on certain terminals, (s)he can register those terminals. As registrations are on the fly conditions,

they are evaluated first, to try to find a suitable terminal where the user is currently traceable. If there is no suitable registered terminal, the algorithm processes the user’s Virtual Desk, which represents the group of terminals that the user owns and/or by which (s)he is usually reachable. Examples are the mobile phone, the office phone, the PC address or the default mailbox. This means that if the user is not responding on any terminal, then the communication request cannot be served and it is rejected. Evaluate Registrations: if exists registration Ri then forward the communication request to Ri break 2exit % jump to end of algorithm fi end % registration evaluation Evaluate Virtual Desk: if exists configured terminal Ti then forward the communication request to Ti break 2exit % jump to end of algorithm fi end % virtual desk evaluation

2exit % end of algorithm For example, in Anna’s policies of Figure 3, if a communication request arrives of type SynchService, we can observe that no policy is valid if (a) the time-period is outside the scope of policy I, and (b) the caller is not identified as in policy III. Therefore, in this case communication request is to be served on a traditional basis: if Anna is registered on a synchronous terminal (e.g. a phone number) this will be used to route the call (similarly for the Virtual Desk2). Advanced aspects concerning policy evaluation are termination conditions and policy generalization, which are deeply discussed in the following two Sections.

2.6. Conditions for Evaluation Termination When a user is addressed with a communication request, active policies are evaluated and the first valid policy is fired with the execution of all associated actions. This simple behaviour gives raise to a rather complicated variety of cases, which need to be handled correctly in order to terminate the evaluation algorithm in a finite time.

2 Registrations and Virtual Desk can be configured by the user, and stored in the User Profile (together with policies), as described in [12].

Whenever a policy fires, its execution can result in an exception, which needs to be associated with the correct communication request. Furthermore, as a single policy can originate multiple actions, in the worst case each action can return an exception. This situation must be managed carefully, to avoid an explosion of parallel execution threads. In simple words, two aspects need further discussion: management of exceptions, and execution of parallel actions. In general, both cases need the association of the communication request with a session identifier: when the event arrives, the system must open a new session, assign a unique session identifier, and try to solve the request with a valid policy. Figure 4 shows that the number of communication threads will correspond to the number of actions associated with the event: each thread can be executed in parallel inside the same session. Hence, if event E is associated with a policy P defining n actions A1 ... An, each action will be launched. Termination depends on the number of times the system should try to serve each single communication thread: if a communication request yields an exception, the user can define a policy specifying how to handle that case. Of course, this policy can in turn yield an exception, and this can result in an infinite evaluation process. In our Figure, if each action fails, it raises an exception that (associated with original event E) will possibly match with a defined policy which on its own could define an action list (e.g. policy P11 defining actions A11... A1j for exception on A1), and so forth. To solve this problem, in a certain session an exception is processed only once: if another exception returns for an already exceptional session, then policy evaluation is not started and the communication request fails. event E

P

thread 1

A1 .. . .. ..

thread n

An

Event E ∧ Exception on A1

P11 .. .

Event E ∧ Exception on A1 Event E ∧ Exception on An

Legenda:

new threads due to exception on action Awz

... thread 1j

P1s

...

Pn1

...

.. .

Event E ∧ Exception on An

thread 11

Pnk

A11

.. .

A1j

.. .

... STOP

Figure 4. Recursive exception handling This solution is based on the observation that, from a user perspective, exception handling is associated with the direct failure of a normal behaviour. In this sense, to support recursive exceptions is more a algorithmic exercise than a real need. We can also observe that thanks to simplicity of topdown evaluation, the policy engine simply restarts

evaluation each time from scratch, with no need for stateful execution. Non-finite evaluation can also occur in case of cyclic redirection, i.e. when a call request is redirected to another person in a cyclic way. In this case, the communication handling system must recognize that, in the same session, a communication request is addressed to a user twice. Generic cases of cyclic redirection are depicted in Figure 5. Top-down, the first case is a trivial still possible case, in which user A calls himself (i.e. sends a communication request to his own address): this case can be handled as self-redirection, and in general treated as an error.

A

1. call

2. redirect to A 1. call

A

B

3. call

A

1. call 5. call

C

B

2. redirect to C

3. call 4. redirect to B

Figure 5. Cyclic redirection The second case of Figure 5 involves two users: user A calls user B. Let us suppose the worst case, in which each user defined a policy, valid for the current call and redirecting to another user. In this case, if user B set a policy redirecting the call back to A, then the call originated by user A will be sent back to A. In this case, by keeping track in the ongoing session of the sender identifier, we avoid to send a call back to its sender. At last, the third case involves three users, but it can be applied to the general case of multiple users. In this case, a call is originated by user A toward user B, which starts cyclic redirection with user C. In this scenario, to keep track of the sender is of no help as cyclic redirection can happen among any chain of users involved in the session. To support also this scenario, the solution must be more general: by keeping track of the chain of involved users, we can simply check that a certain communication request is not sent to a user already involved in the session. Current implementation supports all cases above, by raising a cyclic redirection exception.

2.7. Generalization in Policy Instances Among properties of policies, flexibility refers to the possibility for a policy to be independent from specific terminals, networks and subscriptions. To achieve this

requirement, we suppose that certain elements in a policy instance are defined at the type level, and that they are bounded to specific values dynamically when the policy has to be fired. The following discusses the three main aspects concerning generalization aspects in policy instances. Generalization from the terminal: as defined in Section 2.3, action Terminal identifies the type of terminal to which a communication request is directed. In reality, we observed in the policy samples of Figure 3 that some actions (with terminal type Mailbox, in policies IV and V) are configured with a specific mailbox address. We did not mention the actions not labelled with any specific address: actions in policies I, III and PC in IV, are left generic. At evaluation time, when the corresponding policy results to be valid, a specific terminal address for the corresponding terminal type will be searched according to the usual evaluation algorithm, first among registrations and then (if needed) among terminals in the Virtual Desk. Therefore, if a user wants to be reached by the terminal currently registered, only the terminal type is indicated (i.e. PC, phone, or mailbox). Moreover, an additional terminal type (called generic terminal) is supported. This is a logical terminal, specifying that the user wants to be reached to any terminal (s)he is currently using, with no type limitation: this feature is especially useful to support communication over converged networks. In summary, generalization from the terminal permits to define generic policies that are dynamically applied to the exact user location when the communication request arrives. The advantage is immediate: there is no need to customize policies each time the user changes location. Generalization from service subscriptions: a peculiarity of our policy definition is service independence, in both events and actions. Events model a type of communication (namely synchronous or asynchronous), and there is no predefined assumption on the specific service or application used by communication edges. In particular, the caller is likely to use a different provider, and an application not easily identifiable and different from the ones of the callee. Further, policy actions model a termination point (represented as a terminal class) supporting a certain type of communication. Accordingly, the callee can set personalization policies independently from his/her current specific service subscriptions and his/her available applications. Many are the advantages: new subscriptions are automatically considered by policy evaluation, with no modification in policy instances; the provider is free to transparently adapt the current communication session according to available network resources and integration possibilities. As an example, consider policy I. This policy terminates on a PC terminal any synchronous communication request arriving on working hours. In this

case, as the IP address is not configured, the user is free to change location, by registering e.g. his/her office desktop, a PC in the labs, or an IT terminal in the meeting room: all applicable communication requests will be dynamically forwarded to the current registration. Consequently, (s)he can use any service/application installed on the current PC. For instance, if in the past the user was using a videoconferencing application for both video and audio calls, and if (s)he recently subscribed to a new IP telephony application, this new subscription will be discovered dynamically from the system, and automatically used for audio communication sessions. Of course, it is not a simple task to setup a communication session composed by two independent communication legs (one of the caller and one of the callee). To be able to do that, requirements are that the provider disposes of suitable network resources (discussed in the next paragraph), and that it exists a mapping among each communication type and its compatible services (like the one defined by the service classification in Section 2.1). Generalization from network resources: a direct consequence of generalization from terminal and service subscription is generalization from the specific network resources used by the provider to setup a communication session. The principle is very simple: as the caller can use any communication media, and can subscribe to any service (or use any application), it is up to the provider to recognize the type of resources (e.g. communication protocols, media gateways) needed to support (or not) the communication session. The main advantage is scalability, and immediate (and transparent) customer availability of newly introduced network services.

3. System Architecture The architecture implementing policy-based personalization (called UNIK, UNIversal Kit) is made-up of a set of components supplying advanced middleware features, i.e. general-purpose features usable by heterogeneous applications, services, terminals and networks. The overall objective of UNIK is to integrate a set of distributed components, which manage and possibly hide network details, and which offer public interfaces (or APIs) toward end-users and third-party applications and providers. The complete UNIK architecture is rather complex: to date, its implementation integrates fixed telephony with communication over the Internet, by using a set of network resources for network convergence, and by experimenting a number of end-user applications and terminals (both commercial and free prototypes). As this paper focuses on personalization aspects, Section 3.1 will highlight just the main UNIK components and associated functionality, directly implementing our policybased approach, and Section 3.2 presents a simple example

scenario of personalization at work. Further details about the complete UNIK architecture can be found in [10].

• Anna’s policies also include the following eventexception policy:

3.1. Components and Functionality The central part of Figure 6 shows UNIK components in the provider domain, interacting with network resources (i.e. media controllers and gateways – the shaded components in the figure – that support network convergence by translating call signalling and media transfer protocols between different networks and standards). In this work we focus on the two crucial UNIK components: the Communication Handling component (CH) implementing seamless network integration, and the Policy Management component (PIPPO, Policy-enabled Intelligent Personal Preferences Object) personalizing for each user the way in which incoming calls are served by the network. The figure exemplifies a group of users accessing provider functionality from different terminals. Middleware features are as follows (see labels on interaction paths between users and architecture components): Authentication: users must be first authenticated (see label “A” near user Paul on the top-left side of the figure) on component Auth that issues an authentication key lasting for the entire user session. All UNIK services comply with a common authentication model, which relies on Auth to control the validity of the authentication key prior to communication provisioning. Registration: as introduced in Section 2.4, it allows the users to inform the provider where to be contacted (see label “R” near in the figure). Current implementation provides a telephony registration functionality, to authenticate and register a phone number (stored in the User Profile for policy evaluation). Personalization: at last, labels “P” in the figure show that users can access personalization information in two ways. For instance, in the figure we suppose that user Paul accesses his personalization information e.g. to modify his policies or to activate a different policy group, while user Anna can access public personalization information of other users (similarly to a white page directory) to find out how to contact a certain user.

3.2. Example Scenario To better show how policy-based personalization is involved in communication provisioning, let us consider a simple example scenario involving hybrid communication over a PSTN-Internet converged network. In Figure 6 squared labels show that user Erik (on the phone) wants to contact user Anna in a synchronous communication (see labels “SC”). To this aim, he types her personal number: this will start policy-based communication processing. We can suppose that the User Profile of Anna includes the policies defined in Figure 3, plus the following:



I.e. if a communication request of type SynchService has been sent to her terminal and the request timeouts raising exception NoAnswer, then two actions are executed: the call must be redirected to user Lara, and a notification is to be sent to Anna’s mailbox. • Anna is currently registered on PC mylab.polito.it. • Her Virtual Desk includes the mailbox address [email protected]. Legenda: A: Authentication R: Registration P: Personalization SC: Synch. Communication AC: Asynch. Communication

Standard interfaces Proprietary/ Network Resource interfaces

Anna

P

P

A

Paul

Auth User Profile

Erik

PSTN Media Controller

Policy-based PIPPO Personalization SUB server subscription server CH

Communication Handling

Gateway/ Softswitch

SC AC

Media Controller Lara

PSTN

SC

Internet

R

SC

Figure 6. Policy-based system architecture Back to our example scenario and following the arrows in Figure 6, Erik’s request traverses the PSTN network and it is forwarded to the CH. This recognizes it as a synchronous communication request addressed to a user identified by a personal number, and it requests component PIPPO to evaluate the policies of the corresponding user and to return the list of actions to be executed in this communication session. Component PIPPO in turn, starts to process Anna’s policies. We see in her list of policies (see Figure 3) that supposing that Erik’s call arrives in the time period defined in policy I, the call is to be sent to an IT terminal.

Therefore, as no specific address is defined in the policy, PIPPO searches for an IP address in Anna’s registrations: the terminal is bound to address mylab.polito.it, which is returned to the CH. The CH sends Erik’s invitation to that address (see label “SC” near Anna). If we suppose that Anna does not reply, the invitation timeouts and the exception NoAnswer is raised back to the CH. This associates the exception with the correct communication session, recognizes that this is the first time an exception is received in this session, and therefore asks component PIPPO again to evaluate Anna’s policies and return the list of actions to executed in this communication session, this time with exception NoAnswer. In this case, the matching policy is the one added above, according to which two actions are to be executed by the CH: 1. Erik’s call is to be redirected to user Lara: to this aim, the CH asks component PIPPO to evaluate Lara’s policies to find out her personalization. Supposing that Lara’s matching policy is to send synchronous communications to the registered IT terminal, she will get Erik’s call as labelled in Figure 6 (see double-headed arrow towards Lara with label “SC”). Supposing this time Lara accepts the call, the CH will be in charge of providing a Phone-to-PC communication session over the PSTN-Internet converged network. Thanks to available network resources, the current implementation supports this scenario by using two media controllers (one for each network) and a gateway for protocol translation between the two networks (see dashed lines among network resources). 2. Erik’s call request is to be notified to user Anna, by sending an asynchronous notification to her mailbox: as Anna’s Virtual Desk includes mailbox [email protected], the CH is in charge of sending an email to this address (see doubleheaded arrow towards Anna with label “AC”). In summary, this scenario evidences the following important aspects. From an end-user perspective: • Unified communication is achieved by identifying users with a logical identifier (e.g. username or personal number) that is independent from any specific network numbering or terminal in use. • Communication personalization and network convergence are completely transparent: in our scenario, Erik and Lara are not aware to be using heterogeneous terminals, and are not aware of the complex processing behind their communication session. In this respect, a policy-based approach is very general, by modelling complex scenarios in a rather flexible way.

Also, personalization provides a very simple and easy way of adapting services to subjective preferences and everyday life style. In this respect, a policy-based approach reveals to be a novel and powerful means to “program a network” about the way to react in certain occasions, and when, where and how to involve the user. The scenario above shows how the policies of Anna are easy to understand, and how powerful can be their application to complex situations. Further, the semantics associated with policy actions can be easily extended to incrementally support the introduction of new services and functionality. To conclude, we think that a policy-based approach provides a powerful and adaptable solution to ubiquitous user personalization in next generation networks, as auspicated in various and very different contexts from personalization for business planning [8] or for Web navigation [15], to personalized network- and service management [17][1].

4. Related Work When speaking of policy-based personalization, two are the topics in the literature to be discussed: personalization support, and policy languages.

4.1. Personalization Support A precursor example of personalization support for computerized distributed systems was PCSS (Personal Communication Support System, [4]), a system adapting TINA (Telecommunication Information Networking Architecture, see [9]) concepts to support communication personalization in terms of personal mobility and traceability. Similar to our work, a PCSS user can define rules implementing automatic reply to invitations. A rule is composed by a set of conditions (on caller identity, time and service) and an action (accept, block or forward): when the conditions are met, the action is executed. Differently, our approach supports policies with multiple actions enabling innovative services and higher flexibility. Concerning exception handling, in PCSS each rule is associated with all exceptions that are supported by the system during the execution of that rule. In our work, also exception handling can be personalized: policies handling exceptions are completely disassociated from those that can cause exceptions: when an exception occurs, policy evaluation restarts like for any non-exceptional event, and all defined policies are evaluated in the usual top-down fashion. At last, PCSS has a complicated architecture, heavily based on the concept of registration: to be reachable, a user must be registered by at least a terminal suitable for communication. This is an important limitation requiring the user to start an access session by the provider, in order to be reachable. We released this limitation by introducing the concept of Virtual Desk: no access session

is required, and configured user’s terminals can always be tried. From an architectural viewpoint, an interesting work is [6] that applied mobile agents and Java technologies to personalization for automated information retrieval. The basic concept is the use of the mobile agent as a personal secretary object (like we use a personalization object to store and apply user policies): by specifying personal interests and topics, the agent navigates the Internet and transparently uploads information, then periodically delivered to the user. Even if this application differs very much from the context of our work, it shows the advantage of mobile technology to solve traceability: in this case, mobile technology achieves proximity to information; in our case it would help in achieving proximity to the user, hence decreasing traffic overload. Nonetheless, the introduction of code mobility must be carefully evaluated to bring real advantages.

4.2. Policy Languages The concept of policy has been widely applied in networking, for which the Internet Engineering Task Force (IETF) defined a policy as a policy rule composed by a set of conditions and a set of associated actions [21]. As evidenced in [20], network policies can be triggered in two ways: either statically (when injected in the network to configure network access and traffic) or dynamically (enforced in the network only upon need, and applied only under certain network conditions, like congestion or QoS enforcement). As a comparison, our policy definition is similar in that multiple conditions and actions can be part of a single policy. Also, our policies can be considered as both static and dynamic: static because when the user activates a policy group, it can be considered as injected in the network, dynamic because policies are triggered only if specific events apply. Further, conditions and actions can be left generic, and hence their values can vary dynamically. The survey in [20] presents major network policy languages. They are tailored for communication control at the network level, and badly adapt to higher-level appliances like user-oriented personalization. Some commonalities with our approach can be found in two networking policy languages reported in [18], Tower and Ponder. Tower aims at role-based access control. It is based on the notion of users, roles and permissions, on top of which it defines a set of authorization policies. Besides the difference in scope, Tower is meant for system administrators, while our language is oriented towards endusers or non-technical customers, by providing both an application level perspective over service usage, and by supporting an intuitive graphical notation. Ponder [3], aims at specifying management and security policies for distributed systems. Similar to most networking policy languages, here policies can be grouped to make up

complex composite policies: a basic policy is composed by a set of rules, each defining conditions of validity, and the actions granted (or forbidden) on some target objects. Additionally, Ponder supports the explicit definition of events, to separate the specification of the events depicting a situation, from applicable policies. In our work, the concept of event is mandatory to discriminate the type of communication request, and to carry out policy evaluation. In fact, while policies for networking are on a very low abstraction level and the triggering event (packet arrival) can be considered implicit and unique, we place ourselves on a higher pane in which policy evaluation has to discriminate among different event types.

5. Conclusions and Further Work We have presented a policy-based approach to personalization of communication over converged networks. A policy-based approach supports users in defining their personalized perception of services on a highlevel basis, and how, when and where to be contacted. In this way, the user is supported in adapting service provisioning to lifestyle and daily routine. Personalization is based on two basic concepts: service and policy. The concept of service has been formalized in a service classification, which provides the necessary abstraction from service specifics, and which permits to define personalization in terms of generic communication types. The concept of policy extends the traditional EventCondition-Action paradigm, by defining a generic policy structure extensible for application contexts other than communication support. Further, we specialized a personalization kernel for communication support, showing how policy-based personalization can be easily achieved. At last, we presented UNIK, a component-based architecture implementing our policy-based personalization approach. Policies and personalization are here applied to communication services over converged networks. Nonetheless, they can include traditional IT or Web-based appliances in a straightforward way, as demonstrated by some experimentations aimed at integrating in our architecture Web-based appliances (e.g. call logging, online service publishing or subscription, or customisable email notification of unanswered calls, [19]). To this aim, class InfoService in Figure 1 models this extension, by representing traditional applications as “information services”: the rationale behind considers each application as a service requiring a unilateral interaction –or communication– with the provider; hence, application usage can be modelled as a communication exchanging information between the user and the provider. In this way, by extending the specialization kernel with the events, conditions and actions modelling information communication, component PIPPO can process these new

policies with the same algorithm. Further details are provided in [11]. From an architectural perspective, abstraction from network details has been strengthen by the separation between policy-based personalization (realized by PIPPO) and its deployment in a real provisioning network (realized by the CH). Therefore, thanks to this separation, and to generality of our policy language, the use of our approach in different environments can be achieved rather easily: by modifying in the CH the semantics associated with policy actions, it is possible to e.g. introduce new network resources or deploy new services with limited impact on the running ones. In this respect, a key role is played by the service classification presented at the beginning of the paper, and on with service deployment is heavily based. The execution environment used for experimentation is currently composed by: two routers CISCO 3640 supporting H.323 and SIP [7], and acting as PSTN media controllers (see Figure 6); a SIP Proxy server acting as media controller for Internet communication; the freeware Elemedia H.323-SIP gateway [5] for hybrid communication sessions. Various available freeware SIP clients have been used from IT terminals. We practically applied our policy-based approach on top of our execution environment, and carried out various experimental projects [11][12][13], running on both the IN of Telecom Italia Lab, and Internet and PSTN from our University labs. These experimentations showed the achievement of our two overall objectives: service abstraction (by applying policy-based personalization independently from the specific services used in the specific project), and openness to network evolution (by introducing new network resources and adapting the CH: again, no modification in our policy-based approach or related components was needed).

6. Acknowledgements The work presented in this paper is the result of various projects in the last three years: I would like to thank all persons that in different ways contributed to its realization. Special thanks go to D. Mana and M. Martino, who worked on the implementation, and C. Licciardi, G. Canal of Telecom Italia Lab, for the many discussions and ideas.

7. References [1] Burchett, C, “Mobile virtual enterprises”. In Proc. of the Working Conf. on Academia/Industry Research Challenges, 2000. [2] Chakravarthy, S., Le, R., Dasari, R., “ECA rule processing in distributed and heterogeneous environments”. In Proc. of the Int. Symposium on Distributed Objects and Applications, 1999.

[3] Damianou, N., Dulay, N., Lupu, E., Sloman, M., “Ponder: A language for specifying security and management policies for distributed systems (Version 2.3)”, Imperial College Research Report DoC 2000/1, Oct. 2001. On-line at http://wwwdse.doc.ic.ac.uk/policies [4] Eckardt, T.O, Magedanz, T., Popescu-Zeletin, R., “Beyond IN and UPT – A Personal Communications Support System Based on TMN Concepts”. In IEEE Journal on Selected Areas in Communications, Vol. 15(7), Sep. 1997, 1308–1314. [5] Elemedia, “Elemedia Gatekeeper Platform, Release 1.4, User Guide”. On-line at http://www.elemedia.com [6] Fiedler, I., “A Distributed Personalized News System based on Mobile Agents”. In Proc. of the 36th Annual Conference on Southeast regional conference (Marietta, GA USA), Apr. 1–3, 1998, 130–135. [7] Handley, M., Schulzrinne, et al., “SIP: Session Initiation Protocol”, IETF RFC 2543, March 1999. [8] Huhns, M.N., Singh, M.P., “Personal assistants”. In IEEE Internet Computing, Vol. 2(5), Sept.-Oct. 1998, 90–92. [9] Inoue, Y., Guha, D., Berndt, H., “The TINA Consortium”. In IEEE Communications Magazine, Vol. 36(9), Sep. 1998. [10] Lago, P. et al., “UNIK Project: Software Architecture and Network Intelligence” Projects Web Page, Politecnico di Torino, http://softeng.polito.it/SoftEng/projects.html [11] Lago, P., “Virtual Presence”, Final Report Contract n. 32/2000 TILab-Politecnico Torino, contribution to deliverable PIR 2.6 Project Eurescom P909 "Enabling Technologies in IN Evolution and IN-Internet integration", Oct. 2000. On-line. [12] Lago, P., Licciardi, C.A., Canal, G., Andreetto, A., “An architecture for IN-Internet hybrid services”. In Computer Networks Journal, Special Issue on Intelligent Networks and Internet Convergence, T. Magedanz, H. Rudin, I. Akyildiz (Eds.), Elsevier, Vol. 35(5), April 2001, 537–549. [13] Lago, P., Licciardi, C.A., Cuda, A., “Internet boosts IN towards new advanced services”. In IEC Annual Review of Communications, Vol. 54, 2001, ISBN 0-933217-86-2. [14] Mana, D. “Development of a System for Virtual Presence”, (Master thesis), Politecnico di Torino, Italy, Dec. 2000. On-line. [15] Mobasher, B., Cooley, R., Srivastava, J., “Automatic personalization based on Web usage mining”. In CACM, Vol. 43(8), S. I. on Personalization, Aug. 2000. [16] Riecken, D. (Ed.), “Personalized Views of Personalization”. In CACM, Vol. 43(8), S. I. on Personalization, Aug. 2000. [17] Ryan, J. (Ed.), “The Converged Network Infrastructure: An Introductory Guide”, 2001. On-line at http://techguide.com [18] Sloman, M., Lobo, J., Lupu, E.C. (Eds.), Proc. of the International Workshop on Policies for Distributed Systems and Networks, Bristol, UK, Springer Verlag, Jan. 2001, LNCS 1995. [19] Spinelli, R., “An Architecture for Publishing and on-line Subscription of Telecommunication Services”, Master Thesis, Politecnico di Torino, Jul. 2001, (in Italian). On-line. [20] Stone, G.N., Lundy, B., Geoffrey, G.X., “Network Policy Languages: A Survey and a New Approach”. In IEEE Network, Jan./Feb. 2001, 10–21. [21] Strassner, J., et al., “Policy Core Information Model – Version 1 Specification”, IETF RFC 3060, Feb. 2001.