- I am not
sure that we really need to specify a “transport” for IS. The reason is
that... It is very likely that a mobility management protocol would
need exchange of certain information between the terminal and the
network in order to perform mobility management. Depending on how the
mobility management protocol is specified and based upon, it is very
likely that the information exchange will be integrated in the mobility
management operation for optimal performance. Thus, while a generic
“transport” for IS could be specified, it is not desirable that it is
mandated to be used, as the IS exchange may be better incorporated in
other operations. Therefore, it appears to me to be more important to
define the various pieces of information that could be needed for IS
exchanges.
I
agree with you that we need to define the information first and we will
do it. However, I don't think it is a good idea to combine the
transport of the information with the mobility protocol. .21 IS
must work irrespective of mobility protocol choice and
in fact information exchange should happen even before mobility
protocol kicks in.
[hong-yon] I am not
suggesting what is better, it all depends. I just feel that such
flexibility and choice is necessary to allow people to determine the
necessary mobility management scheme for their systems. This discussion
could be senseless as it is still not clear what information we are
talking about for IS. Here is my opinion: if the information in IS are
concerned only with the need of exchanges to help the various entities
(terminal, network) to determine the link status/condition, then I
agree that the IS should be completely independent of mobility
management, although its use should be optional depending on what the
mobility management needs. If the information in IS are concerned with
higher/managerial-level information, such as operator, authentication,
etc, then we should not exclude the possibility of integrated operation
with other protocols such as mobility, security, etc. In this case,
imposing such information exchange before mobility protocol kicks in is
not a desirable scheme that design of mobility management would like to
be restricted to.
SD> I agree with you that .21 IS framework should not exclude
the possibility of integrating with other protocols such as mobility
and security. By the same logic, it should not mandate the
integration as
well. We should define the IS independently. Of course,
we need to captute the relevant information that these protocols may
need and iteract with during handover.
- By defining
the information, I mean defining what a specific piece of information
is (semantically) and how is it structured and encoded (syntactically).
Agree. Again, pl. let us know if you have any specific
requirements in mind.
[hong-yon] I am thinking... But I am still struggling to understand
what sort of IS information we are dealing with, as described above.
SD> I understand. Pl. let us know if you come up with
something.
- My thought
is that different mobility management mechanism will be interested in
different set of pieces of information. Thus, the way a piece of
information is defined should allow easily any interested protocols to
ask for and convey it in their protocol payload. Besides, as one cannot
exhaustively identify all pieces of information to be defined, the way
a piece of information is defined should allow easily new pieces of
information to be defined in the future in a co-ordinated manner. One
possibility is to have each piece of information to be defined apply
for an ICANN number for the information type. There can be other ways.
Agree
with you and that's why we want the flexibility in information
definition. We can definitely go to ICANN for a information type and
that should be in the basic set. We should also leave some
flexibility to the operators so that they can define
vendor specific IEs as well.
[hong-yon] I agree.
- As stated
above, it is likely that the query/response could be embedded in a
mobility management protocol, or indeed any protocol that is interested
in the defined information. A typical query, as whole or part of a PDU
(protocol data unit), can include one or more information type number.
The response, as whole or part of a PDU, can include the information
that are asked for.
I
don't think this is a good idea. The very reason we wanted to have .21
IS so that it can work with multiple mobility protocols will be lost.
Also do you think we should suggest adding this feature
to 'n' mobility protocols? Hope not.
[hong-yon] As
described above, it depends what sort of IS information we are dealing
with. For higher/managerial-level information, I know that I may want
to integrate certain information exchange in my mobility management
scheme. This is an area in which the separation between mobility
management and 802.21 is not black-&-white. Thus to FACILITATE
mobility management, 802.21 IS should not restrict how a mobility
management scheme could be established. I am suggesting that the
information should be defined, but whether and how they are used should
be left other protocols for flexibility. Or, if 802.21 is to specify
the IS query/response messages/protocol, it shall only be optional.
SD> Same as above
- I think one
challenge is to identify what information need to be defined to
potentially facilitate mobility management.
It
may be difficult to define all of them now.. That's why the basic and
extended sets idea seems to be better.
[hong-yon] I agree
that it is hard to list the information types now. As described above,
I think we should at least decide what sort of information we will
address in IS: link-level information, higher/managerial-level
information, etc, so we now whether 802.21 should specify the IS
query/response protocol.
SD> There was an attempt to captute these level of details and
you may find that in Section 6 (Introduction) in the current draft. We
will fuurther modify it and address it properly.
|