Overview

Service session continuity implies session’s maintenance during users’ movements. Nomadic users move around between different fixed terminals and can ask the infrastructure to move their sessions from one terminal to one another. For example, a user can open a session on a workstation at her office (departure node) and then ask its movement to her personal computer at home (target node) as Figure 1 shows.

Figure 1: Nomadic User Scenario.

Requirements

The middleware should hide the details of the dynamic re-binding of service components, when the session movement is required, besides it should manage all the session hand-off transparently to the user and possibly to the application components. Moreover, the focus was on realizing the multimedia streaming switch seamlessy, i.e., on eliminating discontinuities in service provisioning perceivable by the final user.

 

Architecture

The proposed solution joins standard C/S basic mechanisms and MA based higher level facilities. Many modules involved in session continuity are also part of the service configuration sub-system, therefore they will not be introduced again. Figure 2 shows the modules involved in this service their layering architecture.


Figure 2: Session Continuity Service Architecture.
The green modules are based on standard C/S solutions, they are present on all the nodes participating in the architecture, but they all interrogate centralized servers. The blue ones instead represents services that run on each node, and do not communicate with any external server. Finally, the orange ones are partially or totally based on mobile agents. In fact, the mobile agent programming paradigm was applied to the aspects that are more dynamic, and that could require more flexibility, also in changing at the runtime the strategies, for example the strategies applied for code downloading and for session movement.

Design and Implementation Hints

Nomadic Client Support Design and Implementation Hints

This facility is based on the ClientAgent, the ProxyAgent and the Plan Visitor Agent, see service configuration page. We assume that the user requires the movement of the session from the departure node, where he opened the session, to the target node, with an appropriate GUI.

Figure 3: Nomadic Movement, the Application Hand-off
The application hand-off, that is shown in figure 3, is done between the Client on the departure node, the first Proxy in the service path to the Server and the Client on the target node. The protocol that we used is detailed in the following, and all the components involved on the departure and target nodes are shown in figure 4.


Figure 4: Nomadic Movement, the Implementation Hints
First the ClientAgent asks the ProxyAgent the endpoint for the Proxy, then it interrogates the DecisionMaker and receives a Plan with the necessary actions to take for the session's movement. The Plan is passed to the PVA that moves to the target node, where it downloads (if necessary) and initialize the Client, initializing it with the Proxy endpoint.
Afterwards the PVA, using the appropriate API, asks the bind of the Client on the target place to the Proxy. After that the PVA sends a message to the ClientAgent which is still in the departure node, triggering its movement to the target node and producing the disruption of the Client; this terminates the application hand-off.

We note that the designed protocol ensures session continuity. In fact, when the ClientAgent migrates, the Client is already present and initialized on the target node, and the streaming has already begun, therefore there is no stop of the presentation during the application hand-off.

 

References