| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Dear all HO ad hoc group: How are you? As you might have already noticed, I uploaded
two contributions regarding the optimized HO re-entry (check C802.16e-04_105_Enhanced Handover Re-entry.doc) and the sector ID and Inter-Sector
HO (check C802.16e-04_105_Inter-Sector-HO.doc).
Although it was uploaded about 18 hours ago, some might complain about
the late upload. So here I explain briefly about Samsung’s position on the optimized (actually
abbreviated based on the Backbone Communication Level definition) HO re-entry
and the Inter-Sector HO along with the sector ID so that those who have no time
to review the whole documents. 1. Optimized HO re-entry (the related
contribution is C802.16e-04_105_Enhanced Handover Re-entry.doc) HO network re-entry procedures for each BCL
(Backbone Communication Level) i)
BCL = 1 If the BCL = 1, the indication of HO and the
MSS original SBC profile is transferred to the target BS, hence there is no
need for the MSS to send SBC-REQ. However, the target BS still needs to send
SBC-RSP. Not to waste additional BW, we propose that
RNG-RSP can append the corresponding SBC-RSP TLV encoded information at the end
of RNG-RSP. ii)
BCL = 2 If the BCL = 2, either the security key can be
reused, or the MSS and the target BS would already have those by
pre-authentication. Hence, we can skip the PKM procedure all. But they still
have to do REG. Only the required element for REG-REQ for the MSS is the HMAC
to authenticate the message. However, it already has the HMAC tuple. (Essentially, for the MSS to add and upload the
message in the re-entry takes a really long time (at least 4 frames upon the
calculation). Hence, we need to abbreviate this procedure as much as possible.)
For the MSS in order to prevent to send another message, the only way is to
unite the message in the essential one (RNG-REQ). Hence, as I mentioned ahead, if
the RNG-REQ carries the HMAC tuple to authenticate that
it is the MSS original message, the problem is solved. The proposed scheme is: 1) RNG-REQ carries
the HMAC tuple and 2) the information to be
transported in REG-RSP would be appended at the end of RNG-RSP. iii)
BCL = 3 The HO re-entry itself is the same as the one
of BCL = 2. However, the only difference in communication is that they can
resume communication without resetting the ARQ state. Another
Component: Indicating the BCL in message To perform
the Re-entry proposed, the MSS and the network should know which BLC can be
supported. The serving
BS should negotiate the BCL and let the MSS know at BSHO-RSP
or BSHO-REQ. And at the
target BS should confirm at RNG-RSP that the HO re-entry performed at which
BCL. In the
contribution, these explanations are made in detail and the changes are
proposed. 2. Sector ID and Inter Sector HO (the
related
contribution is C802.16e-04_105_Inter-Sector-HO.doc) I know there have been intensive discussions
on Sector ID so far. Samsung’s position on Sector ID is that a sector ID should
has the following functionalities: 1) to be able to
distinguish the sectors in the multi-sector BS and 2) to provide the additional
information to reduce the synchronization delay. Currently, no messages of the 802.16 system inform
the MSS of which the preamble is used by a BS or a sector. In HO, another major
delay generating process is synchronization. The long delay in sync and
scanning is due to no knowledge of the preamble index used by the neighbor
sector/BS. Obviously, the preamble index of the neighbor sector can be an ID to
distinguish a sector among many. Hence, we add the preamble index list in the
MOB-NBR-ADV. However, it is not necessary to add in DCD since DCD is for the
sector that MSS are connected currently. In addition to MOB-NBR-ADV, to
indicate the sector in HO procedure (this is necessary for the rest of the
sectors to conserve the BW by not allocating unnecessary fast ranging IE), the
HO messages have the sector ID if necessary. 3. Another comment in FA ID The biggest obstacle to design an FA ID is
802.16e system does not specify the specific BW that the system would be
implemented. I think it should be as short as 1 byte. Actually, the standard
does mention it, but it is too broad (2~66 GHz). What I wonder is if it is possible that the
FA ID is just made as long as 1 byte and not specifying the exact meaning of
the FA ID bit by bit. I hope we can discuss it further later on. Thank you
for reading the long email and see you in the CC. Best
regards, Jung-Won
Kim, Ph. D. --------------------------------------------------------- Jung-Won Kim, Ph.D. Senior Engineer NTP SystemLab. 1 Telecommunication
Systems Division Telecommunication
Network Samsung Electronics Co., Ltd. Office: +82-31-279-3356 Mobile:
+82-10-9530-3356 Email: jungwon74.kim@samsung.com --------------------------------------------------------- |