Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802.21] [Mipshop] Re: Architectural Considerations for Handover InformationServices

Title: Re: [802.21] [Mipshop] Re: Architectural Considerations for Handover InformationServices

From: Subir Das <>
Date: Mon, 17 Oct 2005 18:06:21 -0400
To: Hong-Yon Lach <>
Cc: <>
Subject: Re: [802.21] [Mipshop] Re: Architectural Considerations for Handover InformationServices

Thanks for your input.  My answers below.


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.


            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.
              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.

            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.

              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.

             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.

            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.

[hong-yon] Again, this assumes that the IS query/response protocol is necessary, depending on the sort of IS information we are dealing with.


From: Subir Das <> <>
 Date: Mon, 17 Oct 2005 13:08:34 -0400
 To: Hong-Yon Lach <hong-yon.lach@MOTOROLA.COM> <mailto:hong-yon.lach@MOTOROLA.COM>
 Cc: <> <>
 Subject: Re: [802.21] [Mipshop] Re: Architectural Considerations for Handover InformationServices (was: Re: CARD Discussion Query Discussion)
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.  
Hong-Yon Lach wrote:


From: Yoshihiro Ohba <> <>  <>
Date: Mon, 17 Oct 2005 09:43:43 -0400
To: Hong-Yon Lach <> <>  <>
Cc: Yoshihiro Ohba <> <>  <> , <> <>  <>
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
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
[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.

Yoshihiro Ohba