|
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.
************************************************************************************
|