Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[STDS-802-16-MOBILE] [Re] [STDS-802-16-MOBILE] [Handoff] Harmonization of 04_105_Enhac ed_HO_re-entry



Title: [Re] [STDS-802-16-MOBILE] [Handoff] Harmonization of 04_105_Enhaced_HO_re-entry

Hello Itzik and all,

I feel some confusion about the recent HO Ad Hoc's discussions. If my understanding is not right, please let me know that. I described my understandings in the followings (These are not restricted on the 87r2 documents only.):

1)      The invited ranging (or fast ranging) is not possible in principle during HO in OFDMA PHY, except for the case of the pre-associated MSS having the adjust parameters for the target BS.

If the cells between serving BS and target BS largely differs in the cell coverage, then the timing adjustment must be needed to the MSS before it communicates with the target BS. So in the OFDMA-PHY, the code-based ranging should be carried on for adjusting the timing offset between the cells. But in OFDMA-PHY, the message-based ranging cannot be certified to appropriately adjustable the timing offset without UL preamble, and the non-timing aligned messages in a certain subchannel will give the other subchannels a large interference, therefore we will do the code-based ranging for timing adjustment during initial network entry and HO.

I think the Code-based ranging should be preceded before the RNG-REQ message transfer (for transmitting MSS MAC Address, etc) during the HO process in OFDMA-PHY (which cannot support the message-based Ranging.)

If we can apply the invited ranging only in the case of pre-associated MSS, then we should explicitly describe these in the HO texts.

2)      During the HO process, the IP re-establishment shall not be supported without disconnection of the end-to-end TCP sessions.

In my understanding, the end-to-end TCP session should be disconnected if the IP re-establishment carried on during the TCP session. Because the five parameters (the sender's IP address, the receiver's IP address, the transport protocol number, the sending application's port number, and the receiving application's port number) are assumed to identify a connection, if any of these parameters change (for example, the node assigned a different IP address), the connection will break (i.e., communication will no longer be possible).

Thus, in the case of IP re-established, the connection cannot be maintained and the handover cannot be supported. So, we should make the tunnel between serving BS to target BS while the subnet changed by prohibiting the IP re-establishment. 

And in the Idle mode, we described it as a state of returning all the resources such as CID and IP address, therefore so called Idle mode handover is not a handover (because the connection is not maintained during Idle handover), but only a location update state. In the Idle mode, the IP re-establishment does not occurred because it did not have the IP address from the first time in Idle mode.

So, we do not need to discuss the IP re-establishment during handover and idle mode.

3)      For support the Soft Handover and/or fast BS switching, in my understanding, the current IEEE 802.16d specification should be changed (because it is not supported by current PHY, especially for OFDMA-PHY). But the current PAR of TGe have the scope of backward compatibility with IEEE 802.16d, so we cannot put in the SHO and fast BS switching idea to the TGe specification before we changed the TGe PAR as acceptable for PHY change, even in the case of backward-incompatible to the TGd specification for fully support the mobility feature in the current TGe specification.

For the case of SHO, the carrier permutation mechanism for interference averaging effect for different subchannels in different BSs cannot be maintained. So we can use the Band AMC subchannel concept to the SHO case, but then the BSs should know each neighbor BS's channel and CID allocation status. It needs an supervised controlling entities for BSs such as cellular mobile's BSC concept, and the current BSs should only be the transceivers which have no MAC functions.

For the case of Fast BS switching, the dedicated uplink feedback channel for the MSS in every BS is required to provide the rank and CINR value of the neighbor BSs for every frame to the BSC or anchoring BS. It cannot be provided by using the current message based mechanisms, because it has inherent delays and high overhead for transmitting these information. In cdma2000 1x EV-DO, it can be provided using the small overhead by using the most preferred BS's Walsh covering and transmission of CQI value, but in OFDM or OFDMA it cannot be easy to support.

To solve these problems, we can design the dedicated UL feedback channel, but it will gives us a backward compatibility issue with IEEE 802.16d.

4)      For CID field designing issue, the backward compatibility problem may occur. In IEEE 802.16d specification, The BS-ID is constructed as a msb 24-bit of operator ID, and a lsb 8-bit of sector ID. So, the Jung-won's CID concept which have the separated sector ID of 8 bits and FA-ID of 8 bits is not compatible with TGd spec.

But, we can think about the TGd document's description more deeply. In TGd specification, The sector ID concept is only described in the compressed MAP of SCa and OFDMA-PHY, not in the DL-MAP which is the superset of compressed MAP. In my understanding, the compressed DL-MAP described only as a compression of original DL-MAP by reducing the unnecessary parameters in DL-MAP. But, the compressed DL-MAP described the sector ID concept which is not in original DL-MAP. And, also the sector ID concept is not described anywhere in the TGd specification.

I think, on this issue, the TGd specification have the problem in nature, so we have the right to consider of breaking the backward compatibility with TGd specification.

If we do not change the concept of sector ID in TGd specification's compressed DL-MAP, then we cannot put in the concept of current Handover Ad Hoc's inter-sector handover in the same BS. Because the sector is naturally a base station according to TGd. It will treat as a different type of handover between BSs.


Sincerely,

Chulsik Yoon,
Senior Engineer, ETRI

¿øº» ³»¿ë:

º¸³½»ç¶÷: owner-stds-802-16-mobile@LISTSERV.IEEE.ORG[itzikk@RUNCOM.CO.IL]
¹Þ´Â»ç¶÷: STDS-802-16-MOBILE@LISTSERV.IEEE.ORG
Á¦¸ñ: [STDS-802-16-MOBILE] [Handoff] Harmonization of 04_105_Enhaced_HO_re-entry and 04/87r1
¹ÞÀº³¯Â¥: 2004/06/17 ¸ñ 01:45



Resend with correct subject and handoff tag!
Itzik.
------------------
Hello all,
I have uploaded document named "C802.16e-04_87r2" to the handoff ad hoc
upload directory.
It is my attempt to harmonize documents "C802.16e-04_105_Enhanced
Handover Re-entry" and "C802.16e-04_87r1"
I have used the descriptive text of C802.16e-04_87r1 and added
informative and normative definitions of Communication shared levels
concepts from "C802.16e-04_105_Enhanced Handover Re-entry"
One point though, I don't agree with the concept which was presented at
C802.16e-04_105_Enhanced Handover Re-entry of changing the RNG-REQ
message and adding to it TLVs with different processes.
I think that such approach breaks communalities of MAC behavior with TGd
and other MAC state machines.
The approach that was taken is to clearly define the communication
sharing level, and which procedure is required according to the working
level.
The optimization of the process is done in two levels; first, all the
network entry messages may be transmitted in a consecutive way, in one
frame (assuming to have enough allocation from the BS).
Second, according to the sharing level, some of the network entries may
be skipped. I agree that this adds additional MAC behavior, but it does
it in a high level and not changes the local behavior per process (e.g.
state machine).
I did not receive any additional inputs from Phil and Jung-Won Kim, and
I'm using this medium to seek for comments from the entire ad hoc group.
Thanks,
Itzik.