| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Dear Prakashi
and all I am sorry for
late reply. Please see my
comment in line. Thank you Ronny From:
owner-stds-802-16-mobile@LISTSERV.IEEE.ORG [mailto:owner-stds-802-16-mobile@LISTSERV.IEEE.ORG]
The following harmonized contributions will be
submitted as HO adhoc consensus contributions
prior to the 5 PM deadline on 6/25. Please submit these using the standard
naming conventions (see Brian's earlier email on this subject) to the TGe
upload directory (not the temporary file store). Revisions may be needed next
week based on more thorough review from the group. 1. HO optimization flags r2 - Ronny will try to provide some sample text to
Phil on above points. Text
below is that I have suggested to Phil. (I have changed text in 76r2 using
harmonized terminology) [Insert a sentence to 6.3. 6.3. After the
hand-over request/response handshake has completed, the MSS may begin the
actual HO. At some stage during the HO process, the MSS terminates service with
the serving BS. This is accomplished by sending a MOB-HO-IND MAC Management
message with the HO_IND_type value indicating serving BS release. If the
HO_IND_type field specifies Serving BS release, the BS may either close all connections and
discard MAC state machines and MAC PDUs associated with the MSS, or it may retain the
connections, MAC state machine and PDU associated with the MSS to be forwarded
to the Target BS for service continuation, or to be discarded upon reception of
a backbone message from the Target BS. During handover procedure with the target BS, the MSS will be
notified of pending data existence by post-HO re-entry MSS DL data pending at
Target flag in RNG-RSP. When MSS re-establishes IP connectivity during
receiving forwarded data, BS may send a backbone message to request the old BS
to stop forwarding data. For two
backbone messages please refer to 76r2. (“D.2.XX
MSS-Data-Forwarding Message”, “D.2.XX Stop-Data-Forwarding Message”)
- Unresolved OPEN (Jung-won/Ronny) - currently
there are no HO optimization flags to indicate if an MSS has pending data to
transmit on the UL during HO and IP address acquisition should be delayed.
Needs further analysis but will not gate submission of this contribution today. If there
are only pending data to transmit on the UL during HO, no problem. Because an
MSS can delay address acquisition, it can transmit pending data through the
target BS without breaking session. Problem of
delaying IP address acquisition in UL case is in subsequent DL IP packet
followed by UL IP packet. Even though UL IP packet can be delivered but DL IP
packet will be delivered to the previous BS and this packet has to be forwarded
to the current BS. In this case, we need a way for the previous BS to keep
forwarding DL IP packet. Or MSS
can just send out all pending UL IP packet while delaying IP address
acquisition and re-establish IP address and starts a new session. - Phil will submit a comment with this
contribution 2. NBR-ADV r0 - Phil will submit a comment with this
contribution 3. Method for scanning neighbor BSs periodically 4. Clarification of Paging Announce - BJ Kim will submit a comment with this
contribution 5. 55r5 - resource retain time The following contributions will be submitted by
the respective contribution authors as non-consensus contributions.
Discusssions will continue on the reflector next week to determine if one or
more of these could be revised as needed and elevated to consensus
contributions. * Define_HO_Rangingcodes rev * Safety Channel HO
* Soft HO (SHO) and Fast BS Switching (FBSS) - Current plan is to combine PHY contributions
into one and MAC contributions for SHO and FBSS into one. We also discussed the following new contributions,
with resolution as under: - Kamran/Masoud will submit a comment for
discussion at the July meeting in * C802.16e-04_120r1 - Branislav - Ronny Kim to send out a brief response regarding
this contribution to the reflector HO Adhoc people has agreed on using HO
optimization flag and bit #3 (omit network address acquisition management
messages) tells an MSS whether it needs to re-establish IP connectivity or not
after HO, and we has decided not to restrict a way for the target BS to know
whether the MSS needs to re-establish its IP address or not. If FQDN is an
information for the target BS to decide the necessity of MSS’s IP re-establishment and can be
exchanged through a backbone, then FQDN along with other IDs (Network ID, BGID,
Subnet ID and so on) can be one of possible solutions. |