Re: stds-802-16-mobile: Handoff and Sleep Mode Ad-hoc: Start ofdiscussion
Hello All
Thanks fot your comments on Samsung's contribution.
Please let me make some answers
For Chairman's view, the boundary of backoff region would depend on the number of entry call and HO call and it can be dynamically allocated by the BS through the DL message which includes information to be used to indicate boundary.
And your suggestion looks good and can be alternative in terms of allocation and indication of backoff field. Furthermore, it seems depend on the operation view.e.g how to handle and allocate the boundary would be implementational issues.
However, most important thing would be that the different backoff region should be defined and allocated for each entry call and HO call. So I believe if we make a room for different backoff field allocation on the messgae, everything will be O.K and there will be no any problem.
For Mr Yanover's view
Thanks for your comments. Unfortunately, we did not meet in the last meeting so I had not chance to hear your valuable comments. But I'm very happy to see mail from you...
You are right. Everything depends on the number of HO call and entry call, and statistical charcteristics of the MSS. We may or may not show some statistical references or simulation results. Even we have a simple simulation results chich can be give the evidence to be shown the useful approach of this proposal, But I'm not sure whether the simulation results can be satisfied for you. However, it is hard to evaluate and analysize the enough and reasonable simulation resulta due to so many variables such as MSS characteristics, call characteristics, number of MSS during HO and any other parameters which can be obtained from measurement under real fields..
I believe that the basic purpose of the backoff field would give avoidance of the collision between the calls and the different access delay can be happend according to the backoff field.And the allocation scheme and direction can be treatable and dynamically handled based on the cell load including entry call and HOcall. If the BS does not want to allocate different backoff field, it can do that..However, we don't need to such approache and should allow the way for the performance enhancement.
Furthermore, Because it does not require the major changes and H/W changes, and it can be done simply on the message level, We'd better give minimum directions and way to assist the fast HO in IEEE802.16e specificatin.
Thanks and Welcome further comments and discussions.
Changhoi Koo
----- Original Message -----
From: "Vladimir Yanover" <vladimir.yanover@alvarion.com>
To: "'Itzik Kitroser'" <itzikk@runcom.co.il>; <stds-802-16-mobile@ieee.org>
Sent: Thursday, June 05, 2003 12:52 AM
Subject: RE: stds-802-16-mobile: Handoff and Sleep Mode Ad-hoc: Start of discussion
> Hello All,
> This is about C802.16e/03-28 document. The tool suggested
> for the solution of the problem seems appropriate: allocate for mobile users
>
> a separated initial ranging channel. But it would be more convincing
> with some statistical data. Is the problem really hard? The answer depends
> on traffic/mobility characteristics.
>
> For example, we know that for voice cellular networks busy hours arrival
> rate may reach 3-4 users/sec per cell. If we assume that data terminals are
> not more mobile than cellular
> phones then we may expect same order of maximum arrival rate for 802.16e
> cells.
> If we take MAC frame duration = 5 ms then we have 50-60 frames per SS for
> initial ranging. So we may allocate MAINT region with 1-2 slots once per 5
> frames
> and configure backoff window to 2 or 4 slots and still have 4-5 attempts for
>
> power adjustment of each incoming SS.
>
> Now, what is the role of "fixed" users in this picture? Probably, busy hours
> are those when people power up their SSs in the evening. If 100 such events
> are
> distributed over one hour interval, then we have 36 sec for each user, 10
> times more than for mobile one. Thus, under given assumptions, there is
> just a small interference from fixed SSs. Do we need a separated MAINT
> channel
> in this case?
>
> It would be interesting to hear from other participants of the discussion
> on their view on traffic/mobility characteristics of future 802.16e users
>
> Vladimir
>
> -----Original Message-----
> From: Itzik Kitroser [mailto:itzikk@runcom.co.il]
> Sent: Monday, June 02, 2003 6:53 PM
> To: stds-802-16-mobile@ieee.org
> Subject: stds-802-16-mobile: Handoff and Sleep Mode Ad-hoc: Start of
> discussion
>
>
> Hello All,
>
> Given enough time passed, I would like to start the discussion in the scope
> of this group.
> As indicated in working document the following topics should be discussed:
> ---->
> 1. Contributions to discuss:
> a.C802.16e/03-28: Fast handoff service
> b.C802.16e/03-30r1: Reporting of scanning results
> c.C802.16e/03-31: Sleep mode enhancement
> 2. Clarification on the types of handoff that are supported; currently the
> text implies that two kind of handoff are supported (break-before-make and
> make-before-break) but descriptions are provided only for the
> break-before-make type. I would like to request proposals on
> make-before-break type (relevant to the current Tga/d technology of course)
> 3. Provide message flow diagrams for the Sleep mode and Handoff procedure,
> such diagrams must provide a clear explanation of the actions performed by
> the BS and by the MSS. The diagrams must be considered for different kind of
> scenarios (i.e. handoff success, target BS rejection etc.)
> <----
>
> I would like to open the discussion with item 1.a. "C802.16e/03-28: Fast
> handoff service " contribution:
> This contribution presents the idea of improving the Initial Ranging of MSS
> during handoff by using two backoff types of backoff parameters:
> 1. "Regular" backoff (min) value for initial ranging, called "MAX_BOFF"
> 2. HO MSS backoff (min) value for MSS during handoff time, called "HO_BOFF"
> The backoff window of MSS doing HO will be: [0,2^HO_BOFF] and the backoff
> window for MSS doing regular (i.e. not handoff) network entry will be:
> [2^HO_BOFF+1,2^MAX_BOFF].
>
> The advantage of this method, is that, when using a shared contention
> resource, the MSS performing HO will not collide with MSS performing initial
> network entry.
> The drawback of this method is the inherited delay for the initial network
> entry process for regular MSSs.
>
> My view on this issue is:
> a. One of the main targets of the 802.16 handoff procedures is to make the
> handoff process efficient and fast. Coming for this orientation, we have the
> ability to make the initial network synchronization for MSS performing
> handoff, a contentionless process. This is achieved by using the
> "Fast_UL_ranging_IE", which is sent unsolicited, by the target BS to the MSS
> coming in. If the aspire that most of the MSS will be able to do so, than
> the problem solved by C802.16e/03-28 dose not exists.
> b. If there are subscribers, which still required to perform contention
> entry to the target BS, then due to the fact that the number of MSS that
> performing an initial ranging in a stabilized system is very low, it seems
> more reasonable to make two contention windows, which are overlapping:
> b1. "Regular" backoff (min) value for initial ranging, called "MAX_BOFF",
> backoff window [0,2^MAX_BOFF]
> b2. HO MSS backoff (min) value for MSS during handoff time, called
> "HO_BOFF", [0,2^HO_BOFF]
> When MAX_BOFF is large enough, then the probability of collision is still
> low.
>
> Please provide your views on this issue, deadline is 04/06/03.
>
> Best Regards,
> Itzik.
>
>
>
>
>
> This mail passed through mail.alvarion.com
>
> ****************************************************************************
> ********
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code, vandals & computer
> viruses.
> ****************************************************************************
> ********
> This mail was sent via mail.alvarion.com
>
> ************************************************************************************
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
> ************************************************************************************
>
>