| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hello Eric, Thanks for your comments. See comments below. Best Regards, -Vivek >From:
owner-stds-802-21@listserv.ieee.org
[mailto:owner-stds-802-21@listserv.ieee.org] On
Behalf Of NJEDJOU Eric RD-RESA-REN > >Hello to all, > >I am having a couple of comments on
the current version of the document as agreed in > >Section 2
Definitions >It is a good thing to have
introduced a definition for seamless handover! > >Section 3
Functional Requirements >3.9 and 3.10 >Cost and link utilization are
criteria to be taken into account by a handover policy function in order to
achieve the handover service according to the requirements. >These are NOT
requirements by theirselves! Therefore, I am struggling with understanding what
is requested there. > I agree. This came up in our first teleconference
on 6/15 and we decided to include it as sub-bullets in functional requirements. But it was not clear what explicitly the
requirements were in this case. I suggest we move this under Handover
Policy (section 3.12) as inputs to handover policy function. >3.12 Handover Policy >It
is said "Terminal
Initiated Network assisted handofffs should be given preference
since the mobile terminal has knowledge of all the networks >and applications
running on the device". >I do not agree here as it can also be argued
that Network Initiated terminal assisted mode brings the possibility for the
nework to select the best available >access network for the terminal according
to link utilization and Access Point load information it has and
which the terminal
doesn't. Just letting the terminal have the >final decision could then result in handovers
to access network where the user will experience severe service
degradation because it had ignored such information. > >Therefore
i will suggest just evocating different
possible initiationt/assistance handover modes within the requirements Document
without >mentioning preference on any of them.
This preference should rather be let at the discretion of the hanfover policy
function that can reside either on the >terminal
or the network. > > This was presented in the last meeting in I believe the intent here was to give
initial preference (and not preclude in any way!) to cases wherein the handover
policy function resided on the client as opposed to on the network and
that’s just because it is easier to envisage the terminal knowing about
all heterogeneous networks. However I do like your suggestion of not
giving any preference to any of the handover modes and leaving the requirements
broad based. >Section 4 Architecture >4.1
layer 2.5 >It
is said "The standard shall define SAP(s) for providing layer 1
(PHY), layer 2 (MAC), and layer 2.5 (Mobility Management) information to higher
>layer
entity such as >Again
one of the reason of defining a layer 2.5 model was that it allowed higher
layer mobility protocol not to understand each of the underltying layers as all
>those
layers will now interface tothe 2.5 layer. So with the use of L2.5, information
from PHY and MAC need not anymore be
passed directly to >higher
>layer mobility
protocol as they will be passed to L2.5 wich will present
it to unique format
upwards! > >Section 6 Reference Model >It
is not clear from the document where an input to any particular layer comes
from and which direction (up or down) the output is directed at >We
can further discuss these points tommorrw during the conf call > The L2.5 concept is still evolving. We need to come up with more details/requirements
regarding functionality in L2.5. The Reference model concepts are still
evolving as well… > >Eric
Njedjou > > |