Subject: [seamoby] action item: definition of context transfer (Fwd)

From: Pat Calhoun <[email-masked]>
Date: Thu, 11 Jan 2001 14:33:59 -0800 (PST)

>----------------Begin Forwarded Message----------------<

Date: Wed, 10 Jan 2001 14:50:14 -0500
From: "Hamid Syed" <[email-masked]>
Subject: action item: definition of context transfer
To: "'Patrice Calhoun'" <[email-masked]>

Hi Pat,

I tried to post the "context transfer denition" (an action item for me ) but
unable to do that..There is some problem with the Nortel's server. I dont
know how long that problem would take to solve. Can i request you to post
the attached text to context transfer design team for discussion. I would
appreciate that.

regards

Hamid Syed
****************************************************************************
***********************************

Hi,

Here sre some thoughts on "definition of context transfer: problem
statement". I tried to focus only on the issues that are related to context
transfer, assuming that the other part of the overall problem i.e. "the
context information identification and collection" has already been taken
care. So it assumes that the context information is collected and maintained
by a "single functional and physical" entity in the network and this entity
would be responsible for distribution of the context information as well

Feel free to post your comments

- Hamid Mahmood Syed

******************************************************
The context transfer is a mechanism (or a collection of meachanisms) after
completion of which the targeted entity(ies) (the access router) establishes
sufficient conditions to support the microflow(s) of a roaming mobile
without disrupting the service level. The context transfer does not
guarantee that the actual microflows would also be handed over to any or all
of the entities (access routers) that receives the context information. The
activity of defining a seamless context transfer may involve the following
issues to resolve;

1. selection of a generic architecture for context transfer
Two architectures can be discussed here: Centralized Vs Distributed

The first approach assumes a single central entity in the network or in a
defined domain that maintains the updated context information on behalf of a
set of access routers and is also responsible for distributing it amongst
the potential receivers. This role can be applied. for example, to the
access network gateway, an entity like a policy server or an elected access
router itself. This approach may suffer with scalability issues as the
number of microflow information per mobile per access router could be a very
large data to process and transfer in real-time with minimum delays

The second approach distributes the role of context maintainance and
distribution to the access routers itself. This approach seems to be more
appropriate as the access routers hold most of the context information (QoS,
Policy etc). Moreover, the access router is responsible for the context
information or the microflows of the mobiles that are connected thorugh them
which is a scalable 

2.  Defining the sender and the potential receiver(s) of the context
information and "events" that enable access routers become the members of
one "context set or group"
A mobile may have radio connectivity (at least it may receive RF signals)
from more than a single AP. The case where the APs are connected to the same
access router AR, no context transfer is required but when the potential APs
are connected to different ARs, the access routers may expect the mobile's
QoS sessions to arrive. These access routers, therefore, become the
potential receivers of the context information. A "context set" can be
defined as the set of potential access routers in the network that have, or
need to have, the context information related to a mobile. There are few
issues to resolve in the 'dynamic' formation of a context set;

-The addition and deletion of the members to a context set: This could be
triggered by certain network events. These events may be network
policy/configuration conditions that dictate the access routers to join a
context set or could be an event generated by the mobile's movement
prediction that dictates an access router to become the member of a context
set. 
- How does a (potential) new member identify the context set associated with
the mobile?: This requires an 'identifier' for each context set per mobile
and the information of the identifier should be propagated to any potential
member of the context set

3. Transfering the context information
- How does a new member of a context set would know about the sender of the
context?: The context information of the mobile are maintained by some
access router in the network or in other words, there is one potential
sender per context set. The new member need to know who to contact (within
the context set) in order to retrieve the current context. 
-When the context information be transfered?: Two possible approaches are
"reactive" and "proactive or make-before-break". In the later approach, the
context information is transfered to any new member as soon as it joins the
context set irrespective of the fact that the mobile may not choose the
access router for data connectivity. 
- How could any updates in the context be propagated to the members of the
context set and probably any associated events that trigger the context
update need to be understood.

4. Per packet or real-time context information transfer
There are pieces of information that an access router calculates and
maintains on a per packet basis. Metering in a diffserv-enabled router is
one example of such an information. The context transfer solution must
address how and when the per packet information could be transfered between
the access routers and what are the trade offs. For example, for a proactive
case, the transfered metering information may become irrelevantor obselete
at the new access router because of the instant of it was last updated and
the time when the router really needs this information could be large
enough. Even for a reactive transfer mode, by the time the information is
propagated to the new access router , it may become obselete or irrelevant. 

Conclusion:
In order to enable a seamless context transfer, any necessary
mechanisms/protocols are required to answer the issues listed above. 

>----------------End Forwarded Message----------------<