Subject: RE: [Mipshop] Possible Solution to Duplicate Problem?

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Mon, 29 Aug 2005 13:54:28 -0500

Hi Theo, 

Please find my inline replies. 

Regards,
Ajoy 
 
> Ajoy-> What I meant here is that 
> MN should prepare for L3 handoff (sending FBU, HI, HACK) once L2 handoff is decision is made. 

IMO this cannot happen. You cannot 'make' first the L2 handoff decision 
because
   1) such decision is SNR based and effected at the link layer not at 
the IP layer. If you are suggesting that FMIPv6 does such thing, this is 
guarranteed to be technology dependent since not all technologies behave 
like that. Also this does not under ANY light qualify as an L2-trigger 
but as an L2-rape (i.e. serious layer violation).

, because you must detach first from the previous AP. You may have an 
indication of possible AP candidates, but the ultimate selection is made 
by SNR at the link layer not by the IP layer AFTER detachment. Even if 
the selection is made before detachment

Ajoy-> Fast Handoff requires link layer trigger to initiate IP handoff. How does it matter if the L2 trigger is sent after link 
layer handoff decision is made or before that? We did implement low latency handoff (not FMIPv6) using CDMA cellular at that time we used link layer trigger once handoff decision was made and that worked reliably for Post Reg handoff. If you want to implement FMIP reliably, however, you will need two way communications between L2 and L3. L2 will send link layer trigger as soon as link layer decision is made by it to L3 (note that there is a difference between handoff decision and handoff execution). L3 will use this trigger to initiate FMIP preparation signaling. As soon as L3 handoff preparation is complete, L3 will inform L2 to associate with the selected AP that is to execute L2 handoff using selected AP. I think this will make fast handoff more reliable and predictable. However, to make this work, we will need sufficient overall between neighboring AP(s) otherwise call might drop. Please note that I am NOT saying that FMIPv6 will work reliably if you do this for all link!
  layer. But someone will have to implement and validate this. 

> 
> 
> Let me comment inline in your model where necessary
> 
> If you tightly couple L2/L3
> 
> 
> 
>>handoff detection and execution you should not encounter the issue that 
>>you are raised. See below an example handoff execution sequence that can be followed:  
>>
>>   a. Discover information about neighbors using CARD and other link 
>>      layer mechanism. This is done ahead of handoff initiation. 
>>   b. Invoke your handoff control algorithm as soon as signal strength of 
>>    connected link falls below a given threshold say T1. 
> 
> 
> Threshold T1 is for detachment NOT for attachment. The fact that you 
> detach from one AP bears NO relevance to where you attach!!!! 
> 
> Ajoy-> T1 threshold is used to initiate selection of appropriate AP for 
> L2 handoff. At this point you might have list of potential AP(s) or may decide to obtain such list using mechanism such as CARD and by selectively scanning of Neighboring AP(s). This is needed because you do not have to initiate handoff algorithm as long as connected link is in good condition.  
> 
> Even 
> GPRS/GSM on soft handoff initiation 
> 
> Ajoy-> Btw, I have never heard of GSM soft handoff. Soft handoff is used by 
> CDMA. Soft-handoff has nothing to do with Mobile/IP handoff. In CDMA network, 
> Mobile/IP handoff is performed during hard handoff.  

The term GPRSGSM was used to refer to the cellular network.

I am under the impression that GSM is soon to be obsoleted byt 
GPRS/EDGE/UMTS nets. Do you honestly think tha,t Fast Mobile IPv6 will 
be  considered on pure GSM networks???? I hope not otherwise we base our 
design on a technology that is soon to be obsoleted by new standards AND 
implementation on the core net infrastructure!!!! Realistically FMIPv6 
should be expected to be part of the LTE plans not of GSM (I would like 
to see which pure GSM networks will bother with MIPv6/FMIPv6). We design 
for the short/medium/LONG term future, not for tomorrow. Do you really 
think that a GSM network will switch its voice call architecture.

Ajoy-> I was commenting about your use of soft-handoff for GSMGPRS network. 
Soft-handoff is used by CDMA radio. For example, in 3GPP based system, 
Soft-handoff is used by UMTS/ HSDPA/ HSUPA etc link.  I do not believe GSM/GPRS will deploy FMIPv6 for intra-technology handoff. However, I do think there is still opportunity for Mobile/IP handoff for HSDPA/HSUPA but not sure yet. I am not sure if existing FMIPv6 will be sufficient or some 
enhancements will be required though. Personally, I think low latency 
PostReg type of scheme will be better suited for these radios as well. 

We currently have W-CDMA implementations. We are moving to HSDPA and 
then Enhanced UL. And the best example you mention is the GSM network of 
'99 ???? I definetely not convinced now for the soundness of the mechanism..

Ajoy-> I know this. My comment about FMIP handoff was not specific to GSM. 
My comment is applicable to UMTS/HSDPA/HSUPA or any other next generation radio. What I meant is that you can modify RNC RRC protocol to send link layer trigger once handoff is decision is made by it. Typically RNC RRC protocol will decide about link layer handoff by processing various measurements from 
mobile node.  This trigger can be used by FMIP to prepare for L3 signaling. As soon as L3 signaling is complete, L3 can inform RRC that will intern send handoff completion command to mobile node. I have NOT implemented this for UMTS / HSDPA / HSUPA link yet so I am not sure how reliably FMIPv6 protocol work for these link though. 

> 
> Even 
> GPRS/GSM on soft handoff initiation has got transmission over 3 or more 
> BSs since they CANNOT decide with certainty the exact next AP candidate 
> until the hysterisis margin settles down. Even then there is compelling 
> evidence that the Jacobi iteration for the  matrix iterative technique 
> to derive the best SNR _LINGERS_ between BSs with FALSE POSITIVES which 
> will only settle when there are LARGE deviations in each matrix iteration.
> 
> Ajoy-> These are fine details and should be taken care by handover 
> algorithm as described in step a and b. I was giving you high level 
> logical steps not fine details of handoff algorithm. 

Such very big "SHOULD" is not very compelling evidence to assure us that 
it will...Would you base your specification/design/product/robustness on 
a "SHOULD" hypothesis???? I hope not..

Ajoy-> Detail handoff algorithm is implementation dependent so I am not sure 
If we can flush these details during IETF mobility discussion. So, let us assume that FMIPv6 is a signaling protocol for handoff execution and go from there. 

> 
>  >   
> 
>  b. Using signal strength and other policies capabilities in step a, choose appropriate AP that is the potential candidate for L2 handoff.
> 
>>Handoff algorithm should select most appropriate AP at this time. 
> 
> 
> here you do not "choose the appropriate AP" as you conviniently 
> described. The SNR algo even with hysteresis margin tells you WHEN to 
> start looking for a new BS. However
> 
> 
> Ajoy-> Again these are fine details of handoff algorithm and should be taken 
> by step a and b. 
> 
>     1) the search and association occurs AFTER you detach from the 
> previous AP NOT BEFORE!!!!
> 
> 
> Ajoy-> I agree this is how most existing 802.11 NIC works. But if we really want to enable Fast handoff, you have to do smart scanning. 

In cellular network scanning is done while you are connected to existing 
link.

Ajoy, while I am in agreement with the general notion of 'intelligence' 
during an IPv6 handoff, the (at best) abstract 'specification' of 
'smart' scanning for all technologies creates big IFs in the 
specification which in general I am opposed to.

 When I specify something 
I specify it ROBUSTLY, not with a big IF disclaimer and a pinch of hope.

IMO we either have to be specific on this or ACKNOWLEDGE that this is a 
limitation. Otherwise the specificatin promises ultimately a lot and at 
the moment of truth gives us a big IF to hold on to.

More to the point, when you scan channels as you are connected over the 
existing link and you detect MULTIPLE AP, there is no guarrantee that 
your AP selection BEFORE the T1 SNR threshold for detachment will 
coincide with the actual attachment of the MN with a new AP AFTER 
detachment. This is not just because of SNR, but also a combination of 
traffic load and an increased call blocking or even DROPPING 
probability!! So the intelligence you allude to is significant and 
definetely not tackled by the spec. Abstract intelligence IMO is not 
specification but brainstorm..

Ajoy-> Do you think FMIP should specify these details? These are link layer 
mechanisms and perhaps should be kept out of IETF discussion. However, based 
upon implementations if we find that proposed scheme does not work 
for a given link layer then definitely we should try to fix that 
in abstract manner without going in link layer details. 

> 
> 
>     2) the indication that you have from mobility/routing neighbourhood 
> mappings (i.e. AP/AR mapping) BEFORE the detachment in MULTI-AP overlaps 
> that are available concurrently, is NOT indicative of which AP you will 
> eventually select during L2 handoff period. 
> 
> 
> Both RNC/GPRS and 802.11 do 
> exactly this and for GPRS this EXACTLY why their soft handoff does NOT 
> have a single EXACT BS candidate for the handoff.
> 
> For GSM/GPRS the pilot signals as well as the destined MN data stream in 
> soft handoff mode are received SIMULTANEOUSLY until the MN settles into 
> the cell CONCRETELY.
> 
> Ajoy-> This is where I was disagreeing. You have to plan your system such 
> that this assumption is met otherwise you can not do seamless handoff. 
Even in cellular network once handoff decision is made several messages 
are exchanged for handoff execution.
I am viewing FMIP messages are equivalent to cellular handoff execution 
signaling.

Planning is one thing about an assumption, being able to do it is another..

BTW, this is EXACTLY why a GSM network suffers from a SIGNIFICANT 
percentage of ping-pong handoffs. And how does FMIPv6 manage a set of 
cascading FBUs and respective tunnels???? With the reactive handoff 
case, i.e. welcome back good old MIPv6 handoff latency (if it hasn't got 
worse under FMIPv6).

Previous emails have already admitted the limitations of FMIPv6 during 
ping-pong effects. We must look into solutions for these problems 
otherwise, we ran the risk of serious limitations!

Ajoy-> Network planning to key to any handoff algorithm. Even in cellular 
network handoff won't work if the network is not planned right. 

> 
> For 802.11 we all know that
>              a) the MN cannot detect new APs while in active 
> transmissions. It must change in monitor/probe mode. I am well aware of 
> the efforts about interleaving but they have serious limitations that 
> incurs by itself packet loss (which defeats the point) particularly 
> during a handoff). Basically they sound nice but under average channel 
> load conditions they fail magnificently.
> 
> Ajoy-> This is something we should try to optimize. Do you have any solution to fix this? 

And in fact by cellular you allude to GSM, since as you confirmed CDMA 
uses soft-handoffs techniques. 

Ajoy-> Not really.  CDMA uses combination of soft as well as hard handoffs. 
Most of the CDMA handoffs are soft and softer so Mobile/IP is not applicable in those cases. But there are cases where you will have to perform hard handoff as well. You will require Mobile/IP handoff during hard handoffs. 

> 
>              b) even if it interleaving was in place the temporal 
> location of the MN does NOT guarrantee ANYTHING about the accuracy of 
> the selection, particularly when MULTIPLE-APs are around. This is 
> because advanced detection of APs (i.e. interleaved) and ultimate 
> detachment and L2 handoff (i.e. active scan) cannot be guaranteed to 
> yield the SAME AP (i.e. the one selected in advance with the one 
> ultimately selected during the scan phase).  I am NOT talking about the 
> trivial case of a 2-cell ovelap. This is NOT the average case.
> 
> 
> > 
> 
> 
>>   e. If signal strength of connected link falls below a given threshold 
>>      and you are unable to complete proactive signaling then associate with 	the selected AP and follow the reactive handoff scenario. 
> 
> 
> well this depend completely on which stage of the proactive signalling 
> the SNR went below the threshold. And the reactive handoff scenario is a 
> MIPv6, i.e. FMIPV6 will have to go through DAD and a few other delays I 
> have found and eventually have the samle handoff latency as MIPv6 (so 
> there we can remove the "FAST" qualifier from the handoff.
> 
> Ajoy-> Ok. Can you share your performance data? 

yes as soon as I am finished with the paper draft.

Ajoy-> Ok, good. 

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Theodoros Pagtzis <[email-masked]>
Date: Tue, 30 Aug 2005 11:08:40 +0100

Hi Ajoy,

a few more inline comments..

Singh Ajoy-ASINGH1 wrote:
> layer handoff decision is made or before that? 

For the simple reason that the L2 trigger denotes detachment. In a 
multi-AP scenario (i.e. not just two APs) what you see BEFORE the 
detachment is NOT guarranteed to be the same AFTER it and more important 
DURING attachment. This is definetely the case for 802.11 and CDMA. In 
fact this is exactly the reason why ping-pongs in GSM/GPRS occur..i.e. 
by making a decision about a BS which appears eventually NOT to be the 
one you settle into; as a result you bounce between cells that cannot 
keep up with the tunnel set up of the FBU signal..

We did implement low latency handoff (not FMIPv6) using CDMA cellular at 
that time we used link layer trigger once handoff decision was made and 
that worked reliably for Post Reg handoff. If you want to implement FMIP 
reliably, however, you will need two way communications between L2 and 
L3. L2 will send link layer trigger as soon as link layer decision is 
made by it to L3 (note that there is a difference between handoff 
decision and handoff execution). L3 will use this trigger to initiate 
FMIP preparation signaling. As soon as L3 handoff preparation is 
complete, L3 will inform L2 to associate with the selected AP that is to 
execute L2 handoff using selected AP. I think this will make fast 
handoff more reliable and predictable. However, to make this work, we 
will need sufficient overall between neighboring AP(s) otherwise call 
might drop. Please note that I am NOT saying that FMIPv6 will work 
reliably if you do this for all link!
> If we can flush these details during IETF mobility discussion. So, let us assume that FMIPv6 is a signaling protocol for handoff execution and go from there. 

No, no and no...details of the handoff algorithm are NOT implementation 
dependent but theoretical performance dependent. I am talking about the 
math here and you say can solve it by implementing the math better...? I 
have never heard that before...A matrix iteration is a matrix iteration, 
the deviations of the SNR are due to FADING and propagation effects, 
even with MIMO..(this is standard textbook theory). How are you going to 
improve this with "implementation"....????  I hope we are not going to 
redefine physics and maths here by MIP management implementation..

> in abstract manner without going in link layer details. 

Of course not. FMIPv6 need not specify link-layer details explicitly. 
However, when it relies heavily on the performance of these "details" to 
the extent that it can "FAIL" to do a "FAST" handoff, IMO the 
specification must "specify" (i.e. the developer deserves to know) the 
pitfalls, BEFORE the developer decides on the tradeoffs!!! Basically we 
must show WHAT FMIPv6 is dependent on, for the purposes of proving its 
latency claims true. In addition, only by admitting where the protocol 
is weak, can we move forward to solve it. Leaving it as a "detail" until 
the vendors hit the wall is wrong, particularly when we can see the 
effect of these details...

t.

-- 
theo
Nets & Mobile Systems Group
UCL-CS