|
Phil,
Dave and All,
IEEE
802 deals with "LAN and MAN standards, mainly for the
lowest 2 layers of the Reference Model for Open Systems Interconnection
(OSI)"
There were many discussions on BS-to-BS communication at
initial stage of 16e. The consensus was more or less
that "we need it though it is out of the scope of 802.16,
let's put it into informational addendum". Compare it to AP-to-AP communication
(802.11F) which is
not a standard document, but "recommended practice" document.
BS-to-BS communication stuff in 16e is not really interop specifications as it
does not
contain spec of underlying network layers for BS-to-BS
interconnection.
Back
to the "anchor problem", I understand Dave's concern because I have yet more
concerns :-(
Section 6.3.20.2.6 in 16e/D4 is
so unclear [including language] that I wrote the following set of
comments/ questions.
I
believe that without clarification of #1 and #5 one cannot really
understand what is going on. Item #4 looks like show
stopper.
Concerning #2, in Portlan I tried to clarify with contributirs of
#170 and #171 what must be model of BS for which SHO/FBSS may be
possible.
Actually for Active Set of BSs there must be a common MAC
controller connected to several PHY transceivers by communication
lines.
If MAC controller is far away from the
transceivers, microwave connection may add tens
of milliseconds to MAC round trip
delay [example: BR-allocation latency].
High delay will harm communication
with all MSSs including those not in SHO/FBSS mode [majority
of MSSs].
To keep delay low we
should have all transceivers close to MAC
processor [e.g. at same backplane].
Anyway, Active Set must contain only those BSs that have common
MAC controller. Apparently such BSs come in sets, so capability to
participate in
Active Set is not individual capability, but rather
group capability.
- There is a need in detailed
specification of PHY scenarios
for SHO/FBS [similar to
"SHO Based Macro-Diversity Transmission Scenarios" in IEEE C802.16e-04/170r1].
For MAC operations there is a big difference between RF level combining, soft
combining and selection diversity.
- The assumption of SHO is that state
machines of MAC [of specific connections] at all BSs from Active
Set are tightly synchronized. At
SHO two BSs must transmit SAME PHY BURST at DL that means concatenation of
same MAC PDUs with same payloads, headers/subheaders, CIDs, BSNs. Can it be
practically implemented other way than having a single MAC processor in which
the whole burst payload is being built and then distributed to several BS
transceivers? Obviously not all BSs will be implemented this way. It
means that ability to participate in Active Set must be a not individual capability of BS but GROUP capability [group consists of BSs having "common MAC processor"]. So the
standard needs a language to describe capability of this type. There must be a
definition of process MSS follows to learn such group capability. Possible
implementation: a "L1 combining group ID" might be assigned to relevant BSs so
that if for two BSs "group IDs" are equal, they have "common MAC processor"
and therefore may be a part of same Active Set.
- All other topics of standard consider
one MSS - one BS relationship. SHO/FBSS topic is the only one that considers
one MSS - many BSs relationship. So there is a need in definition of "anchor
BS -MSS", "non-anchor BS - MSS" etc.
relationship. Operations [like "Anchor BS update"] must be described in
these terms. See also
#4.
- It is not clear from tte text at
which BS the MSS is registered while in SHO/FBSS state. According to the rest
of definitions in 802.16-2004/802.16e, MSS is either registered at certain BS
[then having specific connections associated with specific Service Flows,
security context etc.] or it is not [and then there is no network data
transfer between the MSS and the BS]. If the answer is that MSS in
SHO/FBSS state is not registered to any BS then there are no authentication
relationship and no MAC connections between BSs and MSS and therefore most of
MAC definitions is not applicable.
- There is a need in certain set of
conditions (assumptions) for SHO/FBSS procedures to be applicable (like frame
clock synch - see original
contribution #171r1).
- Definitions of terms SHO and FBSS are absent (see
contribution #171r1).
- Why described "SHO" ["FBSS"]
procedure is referred to as "handover"? MSS may stay registered at certain BS just using
diversity combining of any sort. Seems more logical to redefine "SHO state" as e.g.
"L1 combining with respect to Active Set X " [FBSS as "L2
combining"], both not necessarily
related to any HO. Then handover of certain
type will include a phase when the MSS is in "SHO"
state.
- FBSS is not a good name as the
closest association is changing serving BSs i.e. regular
handover
- Combining
SHO and FBSS specs in same sections makes text too
complicated
The following fragment of the text shows language
problems [my comments appear in
bold]
6.3.20.2.6
SHO and FBSS Decision and Initiation
While in SHO or FBSS, the MSS and the BS
[which BS? There might be several related to the MSS] shall maintain a
list of BSs that are involved in SHO or FBSS with the MSS. The list is called
the Active Set. Among the BSs in the Active Set, an Anchor BS is
defined.
When operating in FBSS, the MSS only communicates
with the Anchor BS for UL and DL unicast messages and traffic [Very
unclear language. All UL MAC Messages are unicasts as they have unicast CID in
generic MAC header; so unclear what is "UL unicast messages". Traffic is carried
as a payload of MAC messages; so unclear what is "messages and
traffic"]. When operating in SHO, the MSS communicates with all BSs in
the Active Set for UL and DL unicast messages and traffic. [See previous
comment about the language. Also does MSS
receive from all BSs e.g. RNG-RSP messages
(which are unicast)? If yes, then which value of time offset (measured at
which BS) is encoded in this
message? ]
Rest
of the text looks similar.
Looks
like the SHO/FBSS text needs to be re-written.
Vladimir
I tried posting this before with no luck. I
Thought I would try again.
Thanks,
Phil
----- Original Message -----
Sent: Saturday, August 07, 2004 11:07 AM
Subject: Re: [STDS-802-16-MOBILE] [Harmonization] Question for
FBSS
Dave,
I stand corrected. Dave is absolutely right.
Neither the language in the original or proposed revision 16e PAR restricts
specification to the PHY and MAC.
Any limitation to the scope for 16e to PHY and
MAC is inferentially inherited from the WG authorization and the PAR
authorization for the base IEEE 802.16-2004 document. Though I can find no
codification of the restriction in the 802 rules, since an amendment PAR
adds/changes material in the original document without capacity to undo or
violate the original documents scope and purpose, I think that an
interpretation of inherited PAR restriction is likely correct. A revision PAR
is another matter and seems to have the ability to supercede the original
PAR. Thus inherited PAR restriction seems less applicable to a
revision PAR. Traditionally,
exception to the inherited restriction in scope and purpose must be
specifically and clearly enumerated in the amendment
PAR authorization and, while an amendment PAR exception might
expand on the base document scope and purpose, it may not
invalidate the base document scope and purpose. So, had we intended for
16e scope and purpose to exceed the PHY and MAC restriction of IEEE
802.16-2004 we would have had to clearly and unambiguously say so in the 16e
PAR.
In this particular instance, I believe Dave's
interpretation of 'Functions to support higher layer...' is flawed. I do not
believe the sentence represents a clear statement of intent to exceed the PHY
and MAC constraints of IEEE 802.16-2004. I draw specific attention to the
distinctive wording 'Functions to
support [emphasis added] higher layer....' We have
traditionally interpreted that sentence to mean that new mobility PHY features
and MAC messaging, including primitives and triggers, would be defined in 16e
to enable or support higher layer mobility communications, beyond the
scope of 16e work. I would argue that the sentence would certainly have read
'Higher layer handoff communications between base stations or sectors are
specified' had we intended higher layer communications to be defined and not
merely enabled by the standard.
Thanks,
Phil
----- Original Message -----
Sent: Saturday, August 07, 2004 1:32
AM
Subject: Re: [STDS-802-16-MOBILE] [Harmonization]
Question for FBSS
> In the Scope of the 802.16e PAR
> "SCOPE:This document
provides enhancements to IEEE Std 802.16-2004 to Support subscriber stations
moving at vehicular speeds and thereby specifies a system for combined fixed
and mobile broadband wireless access. Functions to support higher layer
handoff between base stations or sectors are
> specified. Operation is
limited to licensed bands suitable for mobility fixed/mobile use below 11 6
GHz.
> Fixed 802.16-2004 subscriber capabilities shall not be
compromised"
>
> I would interpret the " Functions to support
higher layer handoff between base stations or sectors are specified." To
mean that inter base station messaging is in scope. Where does the scope
recieve MAC/PHY limitation in its scope. I know that IEEE 802.x pars are
typicaly limited to MAC/PHY if this is the basis then it would have to
explicitly state all other communications. What keeps these messages
form being developed for delivery across the AI as would be the case if using
802.16 to backhaul across another BS to reach another? Doesn't this in
fact offer the possibility of control of handoff functions residing in the
center BS or AKA BSC/APC?
>
>
> David S. McGinniss
>
Distinguished Member of Technical Staff
> Sprint Broadband Wireless
Technology Development Group
> (630) 926-3184 david.s.mcginniss@mail.sprint.com
>
>
>
> David S. McGinniss
>
Distinguished Member of Technical Staff
> Sprint Broadband Wireless
Technology Development Group
> (630) 926-3184 david.s.mcginniss@mail.sprint.com
>
>
>
>
> -----Original
Message-----
> From: owner-stds-802-16-mobile@listserv.ieee.org [mailto:owner-stds-802-16-mobile@listserv.ieee.org] On Behalf Of
Phillip Barber
> Sent: Friday, August 06, 2004 5:58 PM
> To:
STDS-802-16-MOBILE@listserv.ieee.org
> Subject: Re: [STDS-802-16-MOBILE] [Harmonization] Question for
FBSS
>
> Davd,
>
> BS-to-BS communications
standardization is out of scope for 16e. 16e only
> covers PHY and MAC
standardization of the air interface between MSS and BS.
> That is one
reason NetMan was formed.
>
> Thanks,
> Phil
>
> ----- Original Message -----
> From: "Mcginniss, Dave S [NTK]"
<david.s.mcginniss@MAIL.SPRINT.COM>
> To: <STDS-802-16-MOBILE@listserv.ieee.org>
> Sent: Friday, August 06, 2004 4:56 PM
> Subject: Re:
[STDS-802-16-MOBILE] [Harmonization] Question for FBSS
>
>
> > I think the terminology used serving and controlling help
clarify
> discussion. I understand the concept in each case and
agree about the
> hierarchical vs. flat discussed by Mary and
Bill. I also understand that
> the BSC is unfortunately out of
scope! Even with a flat network running
> lets say Ethernet from
an aggregation switch point perspective still flat at
> layer three the
mobility anchor point is important from a backhaul
> perspective.
In addition 802.16e PAR indicates that the inter BS
> communications to
achieve handoff are in scope. Am I missing something in
> the PAR
language procluding the standardization of a BS that serves a
> mobility
anchor point that by the wording would also be a BS providing AI?
> The
AI may not be active or useful to all MSS so let's say it is useful to
>
none but it is positioned to expedite handoff because it is collocated
with
> my switch/Ethernet example. Does extending the messaging to
support a BS of
> this type AKA BSC really fall out of scope of
!
> > 802.16e? >From an operator perspective having
this functionality
> standardized and hence cheaper and interoperable
would be desirable. I
> think the SCOPE statement opens the door
to address these functions and
> facilitate a better long term
solution.
> >
> > Perhaps the entity in the FBSS scenario
should be called the "serving
> > BS" and the entity in the SHO
should be called the "controlling BS".
> > The role of "mobility
anchor point" may be outside the scope of
> > 802.16.
>
>
> > David S. McGinniss
> > Distinguished Member of
Technical Staff
> > Sprint Broadband Wireless Technology Development
Group
> > (630) 926-3184 david.s.mcginniss@mail.sprint.com
> >
> >
> >
> >
> >
-----Original Message-----
> > From: owner-stds-802-16-mobile@listserv.ieee.org
> [mailto:owner-stds-802-16-mobile@listserv.ieee.org] On
Behalf Of Bill Gage
> > Sent: Wednesday, August 04, 2004 7:06
AM
> > To: STDS-802-16-MOBILE@listserv.ieee.org
> > Subject: Re: [STDS-802-16-MOBILE] [Harmonization] Question
for FBSS
> >
> > Are we (incorrectly) using the term "anchor
BS" for two different
> > concepts?
> >
> > Dave
McGinniss appears to be referring to the *mobility* anchor point.
> >
This is the BS (or BSC) that receives downlink packets and distributes
>
> them to members of the active set. The mobility anchor point is
tied
> > to the IP address assigned to the MSS and, in normal
circumstances,
> > remains the mobility anchor point for as long as
the MSS is using that
> > IP address.
> >
> > If
you have a flat network, with a BS acting as the mobility anchor
> >
point, then Dave is correct -- there will be a significant impact on
>
> terrestrial backhaul requirements due to "tromboning" effects.
The
> > total traffic over the backhaul link will be the traffic
associated
> > with MSS served by that BS plus the replicated traffic
forwarded by
> > that BS to other members of the active set for those
MSS where it is
> > acting as the (mobility) anchor. Dimensioning of
the backhaul link can
> > be tricky because you have to make
assumptions about the number of MSS
> > roaming outside the serving
area of the anchor BS, about the number of
> > MSS simultaneously in
FBSS/SHO and about the number of members in an
> > active
set.
> >
> > If you have a hierarchical network with a
centralised entity (e.g.
> > BSC) acting as the mobility anchor point
and distributing traffic to
> > the members of the active set, then
the backhaul link just has to
> > handle the traffic associated with
MSS served by that BS. Dimensioning
> > of the backhaul link is
fairly straight forward because it is
> > ultimately tied to the
capacity of the radio link.
> >
> >
> > Mary Chion
is referring to the BS that, in FBSS, is selected from the
> > active
set to pass traffic to and from the MSS. In a flat network,
> > this
may or may not be equivalent to the anchor BS. In SHO, the anchor
> >
BS is the one terminating the basic CID for a MSS. The role of
> >
"anchor" can change dynamically according to radio link conditions.
>
>
> > Perhaps the entity in the FBSS scenario should be called the
"serving
> > BS" and the entity in the SHO should be called the
"controlling BS".
> > The role of "mobility anchor point" may be
outside the scope of
> > 802.16.
> >
> > Cheers
...
> >
> >
> > >-----Original
Message-----
> > >From: Mary Chion
> > >Sent: August
3, 2004 6:07 PM
> > >To: STDS-802-16-MOBILE@listserv.ieee.org
> > >Subject: Re: [STDS-802-16-MOBILE] [Harmonization]
Question for
> > >FBSS
> > >
> > >
>
> >Dave,
> > >
> > >I think the issues you
raised are cruicial ones. I would like to
> > >try to address some
of them here.
> > >
> > >1. H_Add and H_Delete are
parameters included in DCD message.
> > >They are set by the
network and broadcast to all the MSS in the
> > >BS.
> >
>
> > >2. Active set is part of of contribution for FBSS and
SHO and it
> > >is adopted in the 802.16e.
> >
>
> > >3. You are correct, there should be a limit in the
number of BSs
> > >allowed in the active set. It can be done
by one of the two ways:
> > >a) Since the BS is involved in the HO
process, the BS can limit
> > >the number of BSs in the active set
without changing the
> > >standard. When the MSS send
MOB-MSSHO-REQ message to the BS, the
> > >BS will send the new
active set information to the MSS in MOB-
> > >BSHO-RSP message
and BS can limit the number of BS in the active
> > >set in the
message. It is stated in the standard that "the actual
> > >Active
Set chosen by the MSS shall be a subset of those listed in
> >
>MOB_xxxHO-RSP and shall be indicated in MOB-HO-IND". b) We can
>
> >specify the maximum number of BSs in active set in the
standard.
> > >But, this might not be necessary.
> >
>
> > >4. An Anchor BS is defined as one of the BSs in the
active set.
> > >The role of Anchor BS in Fast BS Switching is to
be the only BS
> > >communicating with the MSS. What's added in
the standard is only
> > >addressing the over-the-air interface.
I'm not sure if I fully
> > >understand what you mean by excluding
a BS to be the anchor BS.
> > >For FBSS, an anchor BS is necessary
for the HO scenario. I agree
> > >with you, if the same data are
sent to all BSs in the active set
> > >BS instead of just to the
anchor BS, there will be a major impact
> > >on backhaul capacity
(especially for services with high speed
> > >data) and it might
not even be an accpetable implementation.
> > >This is an
important issue for network design. However, I don't
> > >think we
can address this issue in 802.16e since 802.16e only
> > >defines
the over-the-air interface. This should be resovled at
> > >system
implentation.
> > >
> > >Please let me know what you
think. Thanks.
> > >
> > >Regards,
> >
>
> > >Mary
> > >
> > >-----Original
Message-----
> > >From: Mcginniss, Dave S [NTK] [
> >
>mailto:david.s.mcginniss@mail.sprint.com]
> > >Sent: Tuesday,
August 03, 2004 5:08 PM
> > >To: Mary Chion; STDS-802-16-MOBILE@listserv.ieee.org
> > >Subject: RE: [STDS-802-16-MOBILE] [Harmonization]
Question for
> > >FBSS
> > >
> > >
>
> >
> > >In the entire example for Fast Cell Switching and
Soft Handoff I
> > >had assumed the anchor was analogous to a
BSC/APC (base station
> > >controller/Access Point Controller)
Only in a decentralized
> > >implementation without this element
would a BS/AP serve as an
> > >anchor. I think the original
question posed by Jay form LG is a
> > >crucial one. If all
the BS in the active set are served the same
> > >data for the MSS
by the Anchor (BS/BSC) this could be a
> > >significant impact on
backhaul requirements. Is there a concrete
> > >methodology
for limiting the active set? I see the H_ADD and
> >
>H_Delete messages but cant see where they are set. The
Neighbor
> > >list can have 255 BS in it. The 802.16E/D4 has
a lot of
> > >information to support FBSS and soft handoff has the
active set
> > >been adopted? Should there be a value to set
a limit on the
> > >number in the active set? Also should
there be a parameter that
> > >if set precludes a BS form becoming
an anchor. As an operator I
> > >would not want a Pico cell
end node with little backhaul serving
> > >as an anchor. If
you can set an option that a BS cannot serve as
> > >an anchor and
FBSS is to be supported then in 6.3.20.2.6 "When
> > >operating in
FBSS, the MSS only communicates with the Anchor BS
> > >for UL and
DL unicast messages and traffic" is an incorrect
> >
>statement.
> > >
> > >
> > >
>
> >David S. McGinniss
> > >
> > >Distinguished
Member of Technical Staff
> > >
> > >Sprint Broadband
Wireless Technology Development Group
> > >
> > >(630)
926-3184 david.s.mcginniss@mail.sprint.com
> > ><mailto:david.s.mcginniss@mail.sprint.com>
> > >
> > >
> >
>
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.
************************************************************************************
|