| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Dear Itzik
and All: How are you? Sorry about the late feedback
about 87r2. Well, I carefully checked out 87r2. But we have the following problems
if 87r2 is accepted. 1) I don’t agree with the phrase that the MSS and the target BS shall
communicate using the mandatory feature until the SBC exchange completes. The
BS already has the MSS original SBC profile. Hence, it is already possible for
the BS to initiate communicating with the MSS using the best fit feature even
before the SBC-RSP. In addition, just waiting to complete the rest of HO
network re-entry message exchanges is, I guess, totally wasting the BW. In
conclusion, I should say from BCL = 1 the BS should concatenate the SBC-RSP (as
you propose) or just append SBC-RSP’s
TLV encoded information (as I propose). 2) As I mentioned just above at the end of the last sentence, I don’t mind concatenating the RSP
messages and sending them to the MSS as you propose. But, (since I still prefer
my option), as you know, the channel quality at the time of HO network re-entry
is poor (maybe better than that to the serving BS). Hence, just concatenating
them can waste a significant amount of BW. 3) In Level 2 & 3, your explanation is not quite clear. I presume
that your contribution proposes that the MSS has to send REG-REQ message after
it successfully received the RNG-RSP message. In Level 2 & 3, the target BS
already has all information to send REG-RSP message. But the only required
information from the MSS is HMAC tuple to
authenticate the MSS. Yet, upon calculation to exchange one pair of message,
the delay takes at least 7 to 8 frames. Hence, I proposed the HMAC tuple is attached the RNG-RSP as TLV. Then, we can just either
concatenate REG-RSP or append its TLV of REG-RSP at the end of RNG-RSP. This is what I think. Please let me know what you think.
And I really appreciate if anybody
gives us any feedback on it. Best regards, Jung-Won Kim --------------------------------------------------------- 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 --------------------------------------------------------- -----Original Message----- Hello Mo-Han, all, Thank you for the comments. My basic approach was to follow the suggestion
from "04_105_Enhanced_HO_re-entry" and try to keep the number of
sharing levels to the minimum possible. The motivation here was first, to reduce the
number of possible cases, and, second, that if the backbone communication level
is sufficient to transfer the security key and security context, than probably
it is logical to assume that service flow information may be shared as well. Any other comments are welcome. Thanks, Itzik. -----Original
Message----- Hi Itzik,
Jung-Won and all, I have a
comment about the current definition of level 2 backbone communication. Level 2
includes transfer/sharing of both the security information as well as service flow
information. I would like to suggest to separate level 2 into two levels.
Basically, we will have the following four levels: - level 1:
transfer/sharing of MSS SBC profile By separating
the transfer/sharing of security information and service flow information into
different levels, we will have more flexibility in actual realization of
network architecture. For example, level 2 context sharing will be for the case
of a centralized anthentication server connecting to multiple BSs. Level 3
context sharing will be for the case of a centralized 'BSC-like/light' node
connecting to multiple BSs. Comments? Regards, Mo-Han -----Original
Message----- Resend with
correct subject and handoff tag! Itzik. 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, |