Hong-Yon,
Thanks for your input. My answers below.
-Subir
Hong-Yon Lach wrote:
Re: [802.21] [Mipshop] Re: Architectural Considerations for
Handover InformationServices (was: Re: CARD Discussion Query Discussion)
Slut Subir,
I am not sure I will be able to attend the call, but here are my
thoughts at the moment, which I am sure can be better explained in
emails than in conversation...
Email should be fine.
- In this
discussion, I assume that IS exchanges take place at or above IP.
Ok.
- 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.
- 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.
- 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.
- 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.
- 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.
- If a generic
protocol is to be specified for the “transport “ for IS, it possibly
should have 2 sets of query/response messages: one for the need of
reliable transmission and one does not require reliable transmission.
The query message can simply include the type number of the information
requested. The response message can include the information requested
in any order in the payload.
Yes, this may be true and we have to take this into
consideration while designing the protocol. This will also depend upon
the criticality of the information,
I may have a very simple view, but I do not
have more issues asking me for something more complicated.
Cheers,
Hong-Yon
From: Subir Das
<subir@research.telcordia.com>
Date: Mon, 17 Oct 2005 13:08:34 -0400
To: Hong-Yon Lach <hong-yon.lach@MOTOROLA.COM>
Cc: <STDS-802-21@listserv.ieee.org>
Subject: Re: [802.21] [Mipshop] Re: Architectural
Considerations for Handover InformationServices (was: Re: CARD
Discussion Query Discussion)
Hong-Yon,
You have raised few good points that we all are trying to find some
answers.
As you know, we are in the process of creating higher layer IS
requirements.
We had one conference call on Oct 11 and will have next call on Oct
25th.
Will appreciate if you let us know your thoughts on higher layer IS
requirements
including some query/response examples, if possible.
Thanks,
-Subir
Hong-Yon Lach wrote:
From: Yoshihiro Ohba <yohba@tari.toshiba.com> <mailto:yohba@tari.toshiba.com>
Date: Mon, 17 Oct 2005 09:43:43 -0400
To: Hong-Yon Lach <hong-yon.lach@motorola.com> <mailto:hong-yon.lach@motorola.com>
Cc: Yoshihiro Ohba <yohba@tari.toshiba.com> <mailto:yohba@tari.toshiba.com>
, <STDS-802-21@listserv.ieee.org> <mailto:STDS-802-21@listserv.ieee.org>
Subject: Re: [802.21] [Mipshop] Re: Architectural Considerations for
Handover
InformationServices (was: Re: CARD Discussion Query Discussion)
On Mon, Oct 17, 2005 at 08:14:10AM +0200, Hong-Yon Lach wrote:
I am claiming that if Solution 1 that provides less semantic query
(one may call it simple query) needs to carry x1 bytes of actual
information with its encoding overhead o1 bytes, while Solution 2 that
provides more semantic query (one may call it complex query) needs to
carry x2 (<x1) bytes of actual information with its encoding overhead
o2 (> o1) bytes, to make the same handover decision, then what we
need
to compare in terms of information volume is [x1+o1 vs. x2+o2],
instead of [x1 vs. x2] or [o1 vs. o2]. And when we are discussing
information encoding, we are just discussing [o1 vs. o2], and choosing
a solution based only on this factor is wrong.
If we view Solution 1 as TLV-based and Solution 2 as XML-based, then I
think [x1 > x2] && [o1 < o2], and depending on how we
encode XML,
diffence between o1 and o2 can be small.
[hong-yon] I think your analysis is misleading. First of all, why
semantic
query cannot be carried out with TLV encoding? TLV has been used to
convey
flexible payloads, which can be of different combination of information
elements. One example is the optional fields; another is that different
information elements have their identifiers to allow them to be flexibly
selected for exchange on a per-need (semantic) basis. Thus, there is no
reason that x1 and x2 are different! Besides, in the overheads, there is
more than just information encoding, there is also the information
structure.
I think if someone comes up with a complete solution that uses
TLV-encoding and also supports semantic query, that could be the best
solution. In fact I have been thinking about such a solution, but it
is just hard for me to come up (probably it is as hard as writing an
application program in assembly language). Just having information
element identifiers is not sufficient for semantic query.
Relationship among information elements also needs to be defined and
utilized for semantic query, and that is why schema is defined in
802.21.
[hong-yon] I wonder how complex we need for semantics in 802.21. It is
not a
clear issue to me to make it a requirement for 802.21. I would like to
ask
ourselves, what is the problem we are trying to solve, what complex
semantic
query we are talking about in 802.21? This is getting pointless and
tiring
in discussing the solution without a clear problem statement.
Regards,
Yoshihiro Ohba
|