Re: [STDS-802-16-MOBILE] [Handoff] Phil Barber action item from H O Ad-hoc conference call on 6/2/04
Prakash,
I don't see utility in just sharing set of CIDs between two BSs [or
sectors].
Could be, when people talk on such sharing, they actually mean another
feature:
a single MAC instance controlling several frequency channels [let me know if
this was the point]. In initial versions of 802.16 this feature was
supported, but
now it is not clear [rather not]. With such feature you might assign each
frequency channel
to a sector and if an MSS goes from one sector to another, it would be not a
handover as MSS
stays attached to same BS MAC instance, with same auth context, connections
etc.
Vladimir
-----Original Message-----
From: Iyer, Prakash [mailto:prakash.iyer@INTEL.COM]
Sent: Tuesday, June 08, 2004 9:27 AM
To: STDS-802-16-MOBILE@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16-MOBILE] [Handoff] Phil Barber action item from H O
Ad-hoc conference call on 6/2/04
Vladimir - with the terminology we're going with, an inter-sector HO for
a multi-sector BS in the real world will be modeled as a BS handover
scenario in which the serving and target BS will have the same BS ID but
different sector ID. In most cases I presume that such a real-world BS
would/could manage a common CID space across these different sectors -
though as you point out it does not have to. Perhaps the expression "may
share MAC resources such as a common CID space or use non-overlapping
sets of CIDs" is more appropriate.
-Prakash
-----Original Message-----
From: owner-stds-802-16-mobile@LISTSERV.IEEE.ORG
[mailto:owner-stds-802-16-mobile@LISTSERV.IEEE.ORG] On Behalf Of
Vladimir Yanover
Sent: Monday, June 07, 2004 8:11 PM
To: STDS-802-16-MOBILE@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16-MOBILE] [Handoff] Phil Barber action item from
H O Ad-hoc conference call on 6/2/04
All
I also am confused. I don't know what is "sharing of [any]
MAC resources between BSs". In the standard it is not defined.
Main MAC resource is air time [per frequency, per subchannel];
how can it be shared between two BSs?
One BS runs exactly one instance of MAC with all associated
resources and there is no provisioning for sharing of resources.
Particularly, sharing of CID space is out of scope of the standard.
If two BSs [e.g. two line cards in same box] decide to use
two different non-overlapping sets of CIDs, it probably will
work ... so what?
Vladimir
-----Original Message-----
From: jay_???
To: STDS-802-16-MOBILE@listserv.ieee.org
Sent: 6/7/2004 6:59 AM
Subject: Re: [STDS-802-16-MOBILE] [Handoff] Phil Barber action item from
HO
Ad-hoc conference call on 6/2/04
Dear Phil and all.
I have a question about inter-sector HO.
In the minutes from conference call , "An inter-sector HO will
essentially be modeled as a HO between a serving and a target BS where
both BS share MAC resources such as a common CID space and essentially
advertise a different sector ID"
I think the underlined sentence is not clear. The shared MAC resources
is only a common CID space ?
Best Regard
jay Jin
_____
From: owner-stds-802-16-mobile@LISTSERV.IEEE.ORG
[mailto:owner-stds-802-16-mobile@LISTSERV.IEEE.ORG]
Sent: Saturday, June 05, 2004 12:41 PM
To: STDS-802-16-MOBILE@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16-MOBILE] [Handoff] Phil Barber action item from
HO Ad-hoc conference call on 6/2/04
Chang-Jae Lee,
See my comments in-line.
Thanks,
Phil
----- Original Message -----
From: Chang-Jae Lee <mailto:cjlee16@lge.com>
To: Phillip Barber <mailto:pbarber@BROADBANDMOBILETECH.COM> ;
STDS-802-16-MOBILE@LISTSERV.IEEE.ORG
<mailto:STDS-802-16-MOBILE@LISTSERV.IEEE.ORG>
Sent: Friday, June 04, 2004 10:01 PM
Subject: Re: [STDS-802-16-MOBILE] [Handoff] Phil Barber action item from
HO Ad-hoc conference call on 6/2/04
Dear Phil and all,
My comments are inline.
BR,
Changjae.
----- Original Message -----
From: owner-stds-802-16-mobile@LISTSERV.IEEE.ORG
<mailto:owner-stds-802-16-mobile@LISTSERV.IEEE.ORG>
To: STDS-802-16-MOBILE@LISTSERV.IEEE.ORG
<mailto:STDS-802-16-MOBILE@LISTSERV.IEEE.ORG>
Sent: Saturday, June 05, 2004 12:03 AM
Subject: [STDS-802-16-MOBILE] [Handoff] Phil Barber action item from HO
Ad-hoc conference call on 6/2/04
I had this action item from the call:
* Phil - Propose new TLV flags to support notion of context ID - to
convey sectors, frequency assignment and subnet/prefix/access router ID
- by 6/8/04
A 'Sector ID' in the form of a BS MAC ID prefix, suffix, or additional
message advertisement through DCD (and, by implication through NBR-ADV)
has already been proposed by Samsung and I am just going to refine this
idea. Allowing for the bifurcation the existing BS MAC ID, exactly as
proposed by Samsung, seems the best approach since it encourages fewer
changes in other places in the document affecting, among other things,
NBR-ADV messages.
I was planning on borrowing ARID use proposed in 802.21 and advertising
it through NBR-ADV. Sticking ARID into DCD seems overkill. And we
don't need ARID in RNG-RSP or SBC-RSP because I am already going to
propose some HO/network re-entry flags in RNG-RSP that will cover that.
My question concerns the FA (frequency assignment) element. My question
is,
1) wouldn't the sector DCD have the required information for FA?
Yes, the DCD have the Frequency param (DL center frequency).
Do we actually require additional MAC level information for advertising
FA?
I think by definition, each sector would have its own DCD, though for
sectored BS using a single frequency/channel assignment, that DCD would
be identical. For sectored BS using different frequencies/channel
assignments in each sector, the DCD would necessarily be different. And
since DCD is imbedded in NBR-ADV, we get appropriate neighbor
advertisement as well.
I think that there is a problem on advertise the DCD for multiple
frequency in a sector.
Because, In Neighbor Advertisement message structure, The TLV only got a
"DCD_setting" per a sector (if we agree on the first paragraph- "Sector
ID").
So, I think we actually require additional MAC level information for
advertising for a FA_ID per multiple FA in a sector.
Actually, I think I will disagree on this one. Since the different FA
would necessitate a different DCD, we can conveniently classify that as
a unique 'sector' channel. The fact that you can have two or more
channels of differing frequencies, occupying the same sectoral coverage
is not relevant. Common sectoral coverage is incidental and not
relevant. As they each must have separate DCDs, we can continue to
regard them as separate 'sectors' for our purposes. I further contend
that your case would only be true if you were discussing two or more
channels of differing frequencies, occupying the same sectoral coverage,
using the same scheduler and expressing the same DL-MAP. As this would
be a highly ineffecient use of frequency, essentially duplicating
traffic on multiple channels/frequencies, I think the deployment
scenario very unlikely. I think the more reasonable model is two or
more channels, of differing frequencies, occupying the same sectoral
coverage, having different DCDs, schedulers and DL-MAPs--effectively
then just two or more 'sectors' that happen to occupy the same coverage.
In that case, the two sectors would be represented by their unique BS
MAC IDs with Sector ID and corresponding DCD--uniquely present in the
NBR-ADV.
I would appreciate feedback on this item prior to my scheduled due date
for submission.
Thanks,
Phil
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.
************************************************************************
************
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.
************************************************************************************