|
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 -----
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
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/
==========================================
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
|