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

Re: [STDS-802-16-MOBILE] [Handoff] Harmonization of 04_105_Enhace d_HO_re-entry and 04/87r1



Title: RE: [STDS-802-16-MOBILE] [Handoff] Harmonization of 04_105_Enhaced_HO_re-entry and 04/87r1

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-----
From: owner-stds-802-16-mobile@listserv.ieee.org [mailto:owner-stds-802-16-mobile@listserv.ieee.org] On Behalf Of
Mo-Han Fong
Sent:
Wednesday, June 16, 2004 11:52 PM
To:
STDS-802-16-MOBILE@listserv.ieee.org
Subject: Re: [STDS-802-16-MOBILE] [Handoff] Harmonization of 04_105_Enhace d_HO_re-entry and 04/87r1

 

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
- level 2: transfer/sharing of security keys
- level 3: transfer/sharing of service flow information
- level 4: transfer/sharing of all MAC state information

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-----
From: Itzik Kitroser [mailto:itzikk@RUNCOM.CO.IL]
Sent: Wednesday, June 16, 2004 12:45 PM
To: STDS-802-16-MOBILE@listserv.ieee.org
Subject: [STDS-802-16-MOBILE] [Handoff] Harmonization of 04_105_Enhaced_HO_re-entry and 04/87r1

 

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.