|
I think you have some legitimate issues with
ambiguity and lack of specification regarding the SHO/FBSS integration into the
HO Process section. I hope that one of the original SHO/FBSS contributors will
take the initiative to address your concerns with a clean-up in the current 16e
recirculation.
Thanks,
Phil
----- Original Message -----
Sent: Friday, August 13, 2004 11:37
AM
Subject: Re: [STDS-802-16]
[STDS-802-16-MOBILE] [Harmonization] Re: Questi on for FBSS
Phil
and All,
I find BS-to-BS stuff necessary and useful. Let me note also
that the 802 practice more or less follows definition of
802 scope. This is the reality .
Concerning SHO/FBSS, I believe there is a bunch of omissions,
ambiguities and inconsistencies. I don't know what is "some type of
stateless HO condition",
so I
cannot judge whether it is true. I have a list of simple questions
and cannot find answers.
When MSS communicates
simultaneously to several BSs [during SHO], is it registered at all of them?
If not, then there are no connections, so impossible to communicate.
If yes, how does it
happen? Section 6.3.20.4 describes what happens at network entry / re-entry.
But is it relevant to SHO? My perception is that SHO is defined as
a middle state
of handover [I say "perception" because
the text is ambiguous] . First state is when MSS registered at
Serving BS, second is SHO, third is MSS registered at [single] Target BS.
This is in line with
6.3.20.2 which defines the HO as "process in which an MSS migrates from the
air-interface provided by one BS to the air-interface provided by another BS".
If this understanding of states is correct,
6.3.20.4 [talking on
network re-entry at Target BS] is not relevant to transition between first
state and second.
So marriage between MSS and BS from
Active Set is not a network re-entry and there is no description of the
procedure.
Contribution #171 [prototype of
6.3.20.2.6] at page 1 provides definition of all involved parties
that confirms above understanding of states [not included in normative
text].
We can speculate more, read more related
contributons, compare our perceptions, but it only means that the text is
ambiguous and probably
inconsistent.
Vladimir
Vladimir and All,
As has been said previously in this list, in
the definition "LAN and MAN standards,
mainly [emphasis added] for the lowest 2 layers of the
Reference Model for Open Systems Interconnection (OSI)", mainly is
not only. There is a very important distinction. And there have been
and continue to be 802 WGs that deal with non-PHY and MAC,
higher layers normative specification. I believe my previous analysis
holds true on PAR scope.
Regarding your observations on the shortcomings
of the approved SHO/FBSS text, I agree that the language needs clarification
and revision. Relationship of Anchor BS as Serving BS comes to mind. I
do not agree that the revision requires creation of the logical constructs
definitions in 16e you identify. I believe that those definitions are more
appropriate in NetMan and not necessary to the MSS-to-BS communications
standard. If it were voodoo magic that made some of those features work
(synchronized BS communications; etc...), it would not matter to the air
interface, so long as it works. Of course we must have confidence that the
features can be reliably implemented in order to justify inclusion in the
standard. Given that those mechanisms work in current cellular technologies,
I think we can have confidence that the mechanisms do in fact work and we
can identify them in NetMan adequately to support their function in
16e.
Your observation that SHO/FBSS uses some type
of stateless HO condition is not true. SHO/FBSS uses the fully optimized HO
mechanism in the standard for BS enjoying full context sharing and state
management, with a minor twist. Essentially SHO/FBSS is no different
than normal optimized HO except that it uses a special HO notification
mechanism and a special control list to assure that the Target BS has all of
its information. But the SHO/FBSS is consummated through RNG-REQ/RSP
optimized sequencing including any necessary re-mapping just like regular
optimized HO process.
Thanks,
Phil
----- Original Message -----
Sent: Thursday, August 12, 2004 2:33
AM
Subject: RE: [STDS-802-16] Fw:
[STDS-802-16-MOBILE] [Harmonization] Question for FBSS
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.
************************************************************************************
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.
************************************************************************************
|