Re: [STDS-802-16] SPAM-LOW: Re: [STDS-802-16] [HO] Usage of "network assisted HO supported flag"

[Malini Raghavendra <Malini.Raghavendra@LNTINFOTECH.COM>]

Hello,

Thanks for the detailed mail !!

I appreciate your interest in getting
across the right perception of the spec procedures.

Thanks,
Malini Raghavendra
Project Lead 
Communication and Embedded Systems, 
Larsen &Toubro Infotech, 
Bangalore,INDIA

"Phillip Barber" <pbarber@broadbandmobiletech.com>

06/28/2006 12:35 PM

To	"Malini Raghavendra" <Malini.Raghavendra@lntinfotech.com>
cc	<STDS-802-16@listserv.ieee.org>
Subject	Re: SPAM-LOW:  Re: [STDS-802-16] [HO] Usage of "network assisted HO supported flag"

How about the descriptive language for the
message:
6.3.2.3.55 HO Indication (MOB_HO-IND)
message
 
An MS shall transmit a MOB_HO-IND
message for final indication that it is about to perform a HO.
Note that the requirement for the MS to transmit
HO-IND does not specify correlation with a MOB_BSHO-REQ or MOB_BSHO-RSP,
only that the HO-IND message be transmitted, if it can be. If you look
at all of the other MAC management messages in 802.16, when paired as REQ
& RSP, the RSP always has language that says 'this message shall be
sent in response to the xxx-REQ message'. HO-IND does not have such language.
 
There are a lot of reasons for the decision
that was made, not the least of which is the likely unavailability of time
to conduct HO-REQ and HO-RSP activity during high mobility. But the network
works much better if it at least gets an HO-IND with the Target BS ID that
an MS intends to handover to. Unpredictive handover (and that is a WiMAX
term coined by Alvarion, not an IEEE term; it is called drop handover in
802.16) does not even require HO-IND to be successful, though it may not
be well optimized. That was intended when we authored this mechanic in
802.16 as well; graceful recovery from marginalized link performance.
 
There is a lot of language in 6.3.22.2.2
HO decision and initiation that talks
about how HO-IND may be used as a response to a BSHO-RSP. There
is even some language that says, in certain circumstances, HO-IND should
be sent. But we had to be very careful. We could not create some unreasonable
rule saying that MS absolutely had to send HO-IND in order to conduct handover
because in mobility, especially at time of intent to handover, the channel
may become so marginalized that transmittal of HO-IND became impossible.
So it is best to think of HO-IND as something the MS should send, if it
has the opportunity.
 
We wrote some complicated language in the
beginning of the section ('The
HO may proceed with a notification...'
and the following paragraph) to try and avoid a race condition for MOB_MSHO-REQ/MOB_BSHO-REQ/MOB_BSHO-RSP/MOB_HO-IND.
But in any instance it is problematic to attribute an HO-IND to a specific
BSHO-RSP. So we made HO-IND both a general response, not to any
specific message, and an unsolicited transmittal whereby the MS could signal
its will not based on any specific message. For instance, MS can cancel
a contemplated handover by sending HO-IND with the Action Code for Cancel
without worrying to which instance of any BSHO-RSP it may refer. It cancels
ALL contemplated handovers. Same thing with rejection. HO-IND with the
Action Code for Reject rejects ALL contemplated handovers.
 
The only time an MS absolutely MUST send
HO-IND is when the MS is seeking to cancel a previously announced (via
HO-IND with Action Code for Serving BS Release) handover prior to expiration
of Resource Retain Timer at the Serving BS. But of course this is not in
response to any HO-REQ/RSP action. This is an unsolicited transmission
to permit the MS to regain Normal Operation with its Serving BS when aborting
a handover attempt.
 
Well, you get the idea.
 
Thanks,
Phillip Barber
Chief Scientist
Broadband Wireless Solutions
Huawei Technologies Co., LTD.
----- Original Message ----- 
From: Malini
Raghavendra 
To: Phillip
Barber 
Cc: STDS-802-16@listserv.ieee.org

Sent: Wednesday, June 28, 2006 12:44 AM
Subject: SPAM-LOW: Re: [STDS-802-16] [HO] Usage
of "network assisted HO supported flag"


Hello, 

Going through the specification of 802.16 one does not get a picture that
MOB_HO-IND is an asynchronous message. 

In my understanding MOB_HO-IND is sent by MS only as a response to previously
received MOB_BSHO-REQ 
or MOB_BSHO-RSP message from serving BS. 

Ofcourse in the uncontrolled or un-predictive HO as per NWG Stage 2 document,
the MS can send MOB_HO-IND 
asynchronously to serving BS after HO. 

Please let me know what sections to refer in the 802.16 specification to
understand your point of view that MOB_HO-IND 
is sent by MS all by itself without previously received HO messages..

Thanks,
Project Lead 
Communication and Embedded Systems, 
Larsen &Toubro Infotech, 
Bangalore,INDIA

"Phillip Barber" <pbarber@broadbandmobiletech.com>

06/28/2006 09:23 AM

To	"Malini Raghavendra" <Malini.Raghavendra@LNTINFOTECH.COM>, <STDS-802-16@listserv.ieee.org>
cc
Subject	Re: [STDS-802-16] [HO] Usage of "network assisted HO supported flag"

Actually, no timer for BS wait on HO-IND was intended. HO-IND is not actually
a response to a specific message (MOB_BSHO-REQ or RSP). You get a race
condition if you make HO-IND a response to a message. You have to look
at the relationship between MOB_MSHO-REQ, MOB_BSHO-REQ, and MOB_BSHO-RSP
carefully and you will see it. Note that the language in the standard says
that MS will send HO-IND to signal handover, not as a response to a specific
message. So BS cannot start a timer because HO-IND is always 'unexpected'.
  
Thanks,
Phillip Barber
Chief Scientist
Broadband Wireless Solutions
Huawei Technologies Co., LTD. 
----- Original Message ----- 
From: Malini
Raghavendra 
To: STDS-802-16@listserv.ieee.org
Sent: Tuesday, June 27, 2006 10:25 PM 
Subject: Re: [STDS-802-16] [HO] Usage of "network assisted HO
supported flag" 


Hello Mr Lee, 
Your perception of Network Assisted HO is now same as mine.

For the issue of Serving BS releasing the resources when Serving BS does
not get MOB_HO-IND, 
it can be done in following 3 ways. 

The referenced sections are in 802.16e D12 Specification.

case 1: Referring to section 6.3.22.2.5 Termination with the serving BS

Regardless of Resource retain timer, the serving BS shall remove MAC context
and MAC PDUs associated with the MS 
upon reception of a backbone message from the target BS indicating
MS Network Attachment at target BS. 

Case 2 when BS detects MS drop, refer section 6.3.22.2.6 Drops During HO
A drop is defined as the situation where an MS has stopped communication
with its serving BS (either in the 
downlink, or in the uplink) before the normal HO sequence outlined in Cell
Selection and Termination with 
the serving BS has been completed. 

When the serving BS has detected a drop, it shall react as if a MOB_HO-IND
message has been received 
with HO_IND_type indicating serving BS release.


Case 3 when BS does not get indication from target BS of successful HO,
Refer 11.7.12.1 System Resource_Retain_Time 

The Resource_Retain_Time is the duration for MSS’s connection information
that will be retained in Serving 
BS. BS shall start Resource_Retain_Time timer at MSS notification of pending
HO attempt through 
MOB_HO-IND or by detecting an MSS drop. The unit of this value is
100msec. 

So even when there is a drop the resource retain timer wll be used by BS
to retain resource for a possible MS 
coming back to Serving BS for resumption of connection.

Another point to note, MSS has T29 and T42 timers which aid MSS is handling
MOB_HO-IND retransmissions, 

A similar timer support is not given at BS[Not in 16e D12 atleast,], so
that BS can wait for a specific time to receive MOB_HO-IND
after sending MOB_BSHO-REQ/MOB_BSHO-RSP. 

This should have been defined by standards committee as it is a common
support provided for any message based protocol handling.

Thanks,
Project Lead 
Communication and Embedded Systems, 
Larsen &Toubro Infotech, 
Bangalore,INDIA

"Chi-Chen Lee" <jjlee@itri.org.tw>
Sent by: chichen.lee@gmail.com

06/27/2006 08:26 PM

To	"Malini Raghavendra" <Malini.Raghavendra@lntinfotech.com>, STDS-802-16@listserv.ieee.org
cc
Subject	Re: [STDS-802-16] [HO] Usage of "network assisted HO supported flag"

Hi Malini,

I like to correct my perception about the usage of Network Assisted HO
supported flag. I think the only difference between Network Assisted HO
supported flag is set to "1" or "0" is that if the
flag is set to "1", MS can send a MOB_HO-IND without specifying
a target BS ID and just using 0x000000 as target BS ID. In contrast, if
the flag is set to "0", MS must specify the target BS ID in MOB_HO-IND.
Thus, the last issue is that, in the case of "uncontrolled HO"
you mentioned, if serving BS not receives MOB_HO-IND, therefore, resource
retain timer will not be started. How can MS decide that it can send MOB_HO-IND
with cancel in some abnormal cases such as drop or failed to handover to
target BS? Or in this case, the MS should not assume the serving BS will
retain the resource allocated to the MS.

thanks,


On 6/27/06, Malini Raghavendra <
Malini.Raghavendra@lntinfotech.com> wrote:

Hello Mr Lee, 

Here is my view on the Network Assisted HO Flag going through the specification.

The Network Assisted Flag in MOB_BSHO-REQ
and MOB_BSHO-RSP
messages indicates to MS 
of serving BS support in specifying the candidate BSs for Handoff .

In this scenario there are 3 cases. 
Case 1: When MS decides to handoff with recommended BSs of MOB_BSHO-REQ
or MOB_BSHO-RSP, 
as per section 6.3.2.3.55 of IEEE 802.16e-2005 MS may choose to send MOB_HO-IND
as a n acknowledgment 
with Target BS set to 0x00000000 which indicates the serving BS of MS deciding
to handoff. 

In which case BS may release its resources allocated for that particular
MS without waiting for resource retain timer to expire. 

Case 2: When MS decides to handoff but does not send MOB_HO-IND, it is
like uncontrolled HO specified in NWG stage 2, 
and BS shall retain its resources till the resource retain timer expiry.

Case 3. When MS does not want to handoff, it may choose to send MOB_HO-IND
with reject/cancel. 

Hence i think the network assisted flag is necessary to be included in
the message and signifies a specific behavior in HO. 

Let me know if there is any difference in opinion. 

Thanks, 

Malini Raghavendra 
Project Lead 
Communication and Embedded Systems, 
Larsen &Toubro Infotech, 
Bangalore,INDIA

Chi-Chen Lee <jjlee@ITRI.ORG.TW>

06/27/2006 11:28 AM

Please respond to
Chi-Chen Lee <jjlee@ITRI.ORG.TW>

To	STDS-802-16@listserv.ieee.org
cc
Subject	[STDS-802-16] [HO] Usage of "network assisted HO supported flag"

Hi,

I have one question about the usage of Network Assisted HO supported flag
in MOB_BSHO-REQ message and MOB_BSHO-RSP message. In my understanding,
if Network Assisted HO supported flag is set to "1" in MOB_BSHO-REQ
or MOB_BSHO-RSP message, MS may perform a handover to any BS among the
recommended BSs without MOB_HO-IND. However, according to section 6.3.2.3.55
of IEEE 802.16e-2005, an MS "shall" transmit a MOB_HO-IND message
for final indication that it is about to perform a HO. It seems that there
is conflict between the usage of MOB_HO-IND and the usage of Network Assisted
HO supported flag. 

There are two possibilities of the above issue:

(1) An MS shall transmit a MOB_HO-IND message for final indication even
though the Network Assisted HO supported flag is set to "1",
i.e. MS behavior has no difference between Network Assisted HO supported
flag is set to 0 and 1. In this case, why we still need Network Assisted
HO supported flag? What does it mean to MS? 

(2) An MS may perform a handover to any BS among the recommended BSs without
MOB_HO-IND. Note that in this case, the MS MAY send MOB_HO-IND with target
BS ID = "0x00000000" as an acknowledgement to the MOB_BSHO-REQ
message but may not send MOB_HO-IND during actual HO. However, this case
incurs another issue: if there is no MOB_HO-IND before MS starts HO, how
does the Resource retain timer work in this case? Without Resource retain
timer, how can the MS decide that it can cancel HO except in the drop case?

I appreciate any comments and discussion on this issue.

thanks,


==========================================
Chi-Chen Lee
Design Engineer
Wireless System Technology Div.,
SoC Technology Center(STC), 
Industrial Technology Research Institute
Tel: +886-3-5914579
Fax: +886-3-5829733
E-mail: jjlee@itri.org.tw
http://www.stc.itri.org.tw/

========================================== 
______________________________________________________________________

______________________________________________________________________



-- 
Cheers,


==========================================
Chi-Chen Lee
Design Engineer
Wireless System Technology Div.,
SoC Technology Center(STC),
Industrial Technology Research Institute
Tel: +886-3-5914579
Fax: +886-3-5829733
E-mail: jjlee@itri.org.tw
http://www.stc.itri.org.tw/
========================================== 
______________________________________________________________________

______________________________________________________________________

______________________________________________________________________

______________________________________________________________________

______________________________________________________________________

______________________________________________________________________