| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi, We already had some long discussion on
this issue during the F2F. I had some different proposal, which simplifies the
ping-pong protection without involving DCD into this process. Unfortunately,
contribution authors thought that we do not have a time to discuss it and
resolve all possible race situations. From my POV this proposal does not have
too much race conditions and provide very simple solution. The addition, change 6, which restrict the
usage of other BS for HO operation mode = 1 may be removed. I added it to be
closer to original Load Balancing proposal. Please, take a look: Change #3:
Enhancement of section “6.3.2.3.42 MOB_NBR-ADV (neighbor advertisement)
message”: For each advertised
neighbor BS, the following TLV parameters may be included: Mobility
Feature Supported Same as in 11.7.14.1. The BS may temporary turn off HO support
bit in the case of overloaded condition and inform other BSs about this
limitation (over the backbone). Change #5: Enhancement of subsection 6.3.22.2.2, HO decision and
initiation: When MOB_MSHO-REQ
is sent by an MS, the MS may indicate one or more possible target BS. When
MOB_BSHO-REQ is sent by a BS, the BS may indicate one or more possible target
BSs. MS may evaluate possible target BS(s) through previously performed
scanning and Association activity. MS shall not attempt HO to the neighbor
BSs, which does not support HO operation or HO operation is temporary disabled
in Mobility Feature Supported TLV of Neighbor BS reflected in MOB_NBR-ADV for
specific BS. Serving BS
criteria for recommendation of target BS may include factors such as expected
MS performance at potential target BS, BS and network loading conditions, and
MS QoS requirements. The serving BS may obtain expected MS performance and BS
and network loading conditions at a potential target BS through the exchange of
messages with that BS over the backbone network. The serving BS may negotiate
location of common time interval where dedicated initial ranging transmission
opportunity for the MS will be provided by all potential target BSs. This
information may be included into MOB_BSHO-RSP message, and is indicated by
Action Time. Serving BS shall not include into recommended target BS list
such BSs, which does not support HO operation or HO operation is temporary
disabled in Mobility Feature Supported TLV of Neighbor BS reflected in
MOB_NBR-ADV for specific BS.. Change #6: Enhancement of subsection 6.3.22.2.2, HO decision and
initiation: In some instances,
the BS may need to force the MS to conduct HO. The BS shall include a value of
HO operation mode = 1 in either the MOB_BSHO-REQ or MOB_BSHO-RSP to signal to
the MS that the MS must conduct HO. Upon receiving a message with HO operation
mode = 1, the MS should treat the HO request as required regardless of
signal quality at Serving BS and shall respond with an HO-IND. MS should send HO-IND with option HO_IND_type = 0b00
indicating commitment to HO unless MS is unable to HO to any of the recommended
BSs in the message, in which case MS may respond with HO-IND with option
HO_IND_type = 0b10 indicating HO reject. An MS required to conduct HO is Change #7: Enhancement of subsection 6.3.22.2.3, HO cancellation: 6.3.22.2.3
HO cancellation After an MS or BS has initiated an HO using either MOB_MSHO-REQ or
MOB_BSHO-REQ message, the MS may cancel HO at any time except of the case
that HO operation mode flag was set to 1 in either the MOB_BSHO-REQ or
MOB_BSHO-RSP. Best Regards Lucy Pollak Senior SW Architect Altair Semiconductor From: Feder, Peretz
(Peretz) [mailto:pfeder@ALCATEL-LUCENT.COM] Jaejeong(Brian) Shim, KiBack Kim, Aeri Lim, Vikas Mehrotra
<javascript:void(0)> , Apurv Mathur <javascript:void(0)> , Simon
Jing, Rishi Arora, Joseph Schumacher, Tommi Rantanen, Zexian Li, Giovanni
Maggi, Aik Chindapol, Tortora Daniele: Before we approve 013r7 ALU
has the following questions: 1) I understand the .ppt file
is not covered this week, nevertheless, what does the following mean in the
power point file? "unsolicited SCN-RSP (with Report mode=0b10, Event-triggered
report) followed by BSHO-REQ message" 2) Not sure why we need the
HO_flag. The idea of providing a target BS (with specific preamble index) at NE
is fine, but why have this BS HO control flag in the DCD? The modified text says it is
to prevent ping-pong. But it does not really solve the ping-pong
problem. What if 4th paragraph in 6.3.22.2.2
already says that MOB_MSHO-REQ takes precedence as it should, since MS knows
better about the RF changes. 3) Also, can we fix the
timing in SCN-RSP in periodic mode (0b01)? It is currently set to 256 frames
(1.275 second) and is too long. Peretz Feder ************************************************************************************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses. ************************************************************************************ |